testdriven.com Wrangling quality out of chaos

Archive for January, 2005

TDD Workshop at MS Tech Center in Austin, TX, March 1

01.31.2005 · Posted in Events

A full day workshop on Test-Driven Development will take place March 1, 2005, at the Microsoft Technology Center in Austin, TX.Synopsis

Test-Driven Development (TDD) goes beyond unit testing by transforming the act of writing tests into detailed software design. TDD serves as a bridge between high-level design and low-level design, or code design. Through test-driven development and design, programmers learn how to produce systems of objects that easier to understand and learn, more appropriate to the requirements at hand, and more resilient to change. Additionally, by introducing thorough testing early into the process, bugs are found and fixed quicker, reducing cost, increasing predictability and driving better software.

The first session, led by Austin-based Microsoft Most Valuable Professional (MVP) Scott Bellware, will introduce the fundamentals of test-driven development practices and development methodology and show how integrate these principles into your projects today using NUnit and Visual Studio .NET.

The second session, led by Microsoft Developer Evangelist J Sawyer, will take a look at the next generation of Microsoft’s developer toolset, Visual Studio Team System, and explore the tools in VSTS for Test Driven Development.

Finally, the afternoon will have an interactive workshop where attendees can learn how to apply TDD’s principles in an interactive, hands-on workshop. Attendees are encouraged to bring laptops so that they can participate in the hands-on workshop. Attendees without laptops will still be able to follow along with the workshop. All Attendees will receive a CD with the sample code from the workshop and free testing tools.
Agenda

9:00 AM – 10:15 AM
Introduction to Test Driven Development
Scott Bellware

10:30 AM – 12:00 PM
TDD with Visual Studio Team System
J Sawyer

1:00 PM – 4:00 PM
Test Driven Development Workshop
Scott Bellware

Speakers: Scott Bellware (Triangle Technologies), J Sawyer (Microsoft)
Day: Tuesday, March 1st
Time: 9:00 AM – 4:00 PM
Place: Austin Microsoft Technology Center

See also:
Announcement on Scott’s site
– [url=http://www.testdriven.com/modules/mylinks/singlelink.php?cid=28&lid=816]Scott’s presentation slides on TDD for managers[/url] (PPT format)

CaseBase, A Testing Framework for C#

01.31.2005 · Posted in Links

Test-Driven Development is best described in the source work of the same name by Kent Beck. Our purpose here is to provide a practical exercise which illustrates the highlights of TDD using a Testing Framework we’ve developed in C#.

CaseBase is a Visual Studio solution, and introduces the concepts of Master (persistent representation of test results) and Monitor (an inspector for Master values).

Authors: Tom Ollar, Jim Bennett
Published: January 27, 2005
link

Free (beta) .NET unit-testing class

01.30.2005 · Posted in News

Elisabeth Hendrickson and Dale Emery will beta test a .Net unit-testing class in Pleasanton, CA, Feb. 9-11.

"Over the last few months, we’ve been hard at work creating a new class, Unit Testing in .NET. Now we’re looking for participants to help beta test it. We thought you might be interested. We’re offering this beta class in exchange for feedback. There will be no fee associated with the class." This is a 3-day hands-on workshop about the core principles of unit testing. Participants will write unit test code in C# using NUnit and related frameworks, and will be testing a realistic application written in .NET throughout the workshop.

Where: Pleasanton, CA (exact location to be announced)
When: February 9-11, 9:00am-5:00pm all 3 days

Contact Dale Emery (dale at dhemery dot com) for additional information.

Python unit testing part 3: the py.test tool and library

01.29.2005 · Posted in Links

Python developers who are serious about testing their code are fortunate to have a choice between at least three unit test frameworks: unittest, doctest and py.test. I’ll discuss these frameworks and I’ll focus on features such as availability, ease of use, API complexity, test execution customization, test fixture management, test reuse and organization, assertion syntax, dealing with exceptions. In this final post I’ll discuss the py.test tool and library.

Author: Grig Georghiu
Published: January 28, 2005
link

Python unit testing part 2: the doctest module

01.29.2005 · Posted in Links

Python developers who are serious about testing their code are fortunate to have a choice between at least three unit test frameworks: unittest, doctest and py.test. I’ll discuss these frameworks and I’ll focus on features such as availability, ease of use, API complexity, test execution customization, test fixture management, test reuse and organization, assertion syntax, dealing with exceptions. In this second part, I’ll discuss the doctest module.

Author: Grig Georghiu
Published: January 27, 2005
link

Python unit testing part 1: the unittest module

01.29.2005 · Posted in Links

Python developers who are serious about testing their code are fortunate to have a choice between at least three unit test frameworks: unittest, doctest and py.test. I’ll discuss these frameworks and I’ll focus on features such as availability, ease of use, API complexity, test execution customization, test fixture management, test reuse and organization, assertion syntax, dealing with exceptions. This post is the first in a series of three. It discusses the unittest module.

Author: Grig Georghiu
Published: January 27, 2005
link

Apache HTTP Test

01.29.2005 · Posted in Links

Apache-Test is focused on designing test tools for the Apache HTTP Server Project. Includes a profile-driven HTTP load tester, a perl-centric HTTP test kit, and modules for SPECWeb99 tests.
link

TDD for beginners, Test-First impediments, Rigid refactoring…

01.28.2005 · Posted in Blogosphere

Riaz Khanmohamed blogs a short TDD for beginners summary: "People use TDD for many different reasons, from developing documentation to testing architecture. TDD in itself is a guideline, so there is no right or wrong, but best practices do exist. Like Agile techniques, they are left up to the user as to whether you use them or not" (this post follows comments on an earlier post).

Frank Sommers wonders whether Test-First Development is an Impediment to Creative Flow: "Writing tests before writing code is a key tenet of extreme programming: Write your tests before you write your code. I find myself violating this XP rule very often. A bit of psychology suggests that test-first development may actually stifle creative flow."

Larry Osterman points out an issue with refactoring: "Refactoring isn’t compatible with public interfaces – once you’ve shipped, your interfaces are immutable. If you decide you need to refactor, you need a new interface, and you must continue to support your existing interfaces, otherwise you break clients."

This links to Bill Venners’ question: Are Tests First Class Clients? "I always felt a bit dirty when making changes to an API solely to accomodate tests. I felt that the tests should be testing the API that would exist if there were no tests, because that’s the ‘true’ API. That’s the API that serves the ‘real’ clients. However, recently I started questioning that attitude. Should I consider tests as first class citizens of the application? Should I see tests as just another client that needs to be served, equal in status to other, non-test clients?"Scott Dockendorf’s recent article Unit Testing with Whidbey made Scott Bellware confused, and it went back and forth.

Yi Zhou makes the case for Spring and Eclipse and mentions Spring is an ideal framework for test driven projects.

Phillip J. Eby decides it’s high time to turn "Stuff" into Action with his to-do lists: "The whiteboard hasn’t been completely cleaned in almost three years, in fact, because it contains a draft of an innovative information model for a business workflow system — one based in small part, ironically enough, on some of the "Getting Things Done" concepts."

Peter Provost wonders about NUnit Assert.AreEquals Parameter Ordering.

François Le Droff made a 24-part report on Javapolis 2004 last december, including entries on Spring, Maven and Agile Offshore.

John Q. Public (Matt?) likes combing his hair but nevertheless makes a nice quick bullet list on development philosophy.

Debugging and Tweaking week MSDN Webcast on TDD in VS.NET

01.28.2005 · Posted in Events

David Waddleton, well-known for his "Geek Speak" webcasts, is presenting a 5-part series on testing and optimization entitled "Debugging and Tweaking Week". The final installment is entitled "Test Driven Development with Visual Studio 2005", and is scheduled for Friday, February 18, 2005, 9-10AM Pacific Time.

Read more about it here.

PHPUnit session led by Sebastian Bergmann at Amsterdam PHP Conference 2005

01.28.2005 · Posted in Events

[url=http://www.testdriven.com/search.php?query=bergmann&action=results]Sebastian Bergmann[/url] will be conducting a session on PHPUnit at the [url=http://www.php-conference.com/konferenzen/psecom,id,262,nodeid,.html]International PHP Conference 2005 Spring Edition[/url].

Description: "PHPUnit supports the development of object-oriented PHP applications using the concepts and methods of Extreme Programming, Test-Driven Development and Design-by-Contract Development by providing an elegant and robust framework for the creation, execution and analysis of Unit Tests. This session will introduce the audience with the concept of Unit Testing and familiarize it with PHPUnit."

When: May 2-4, 2005
Where: Amsterdam, The Netherlands
Registration: PHP conference site

Open Source .NET Development: ASpell.NET Case Study

01.27.2005 · Posted in Links

This chapter is a simple but realistic case study of using Open Source tools in everyday development. In particular, this chapter uses ASpell, a commercial-caliber spell checking component that supports twenty-some different language dictionaries, as an example.

Author: Brian Nantz
Published: Jan 7, 2005
(Sample chapter extracted from Open Source .NET Development: Programming with NAnt, NUnit, NDoc, and More)
link

Advanced Techniques with NUnitAsp

01.27.2005 · Posted in Links

Keeping bugs out of existing code during new development has always been a huge problem. However a new methodology, Test Driven Development (TDD), is helping to change that. The two main principles of this methodology are: 1) Never write a single line of code unless you have a failing automated test, and 2) Eliminate duplication.

In principle this makes sense – we’d all love to have a thousand automated tests, running at the click of a button or command line, which guarantees that our application works. There’s even a popular open source tool, NUnit, which provides a framework for running automated unit tests. While this is very popular with class libraries that just manipulate data structures, it is much more difficult with GUIs.

Fortunately there’s another open source tool, NUnitAsp, which provides a framework to test the GUI’s aspx pages. NUnitAsp is an NUnit extension that provides the extra classes needed to test the HttpContext used by WebForms. Therefore within your NUnit tests, you could load up a page just as a user would see it, taking into consideration the QueryString, Session, ViewState, postback, Web.config, etc… You could then programmatically trigger events and check the resulting properties. This opens up a whole new world for testing techniques.

Author: Tim Stall
Published: January 26, 2005
link

Test Driven Development Using NUnit in C#

01.27.2005 · Posted in Links

When sitting down to create an application, many developers start by writing the code. Test Driven Development emphasizes the opposite, stressing the need to prepare test scenarios or test cases before writing the code itself. This seemingly backwards approach has some benefits. First of all, it requires that the programmer be very clear about what tests the program should pass and what test it should fail, bringing such concerns to the forefront of the software design process. Furthermore, by meticulously detailing what tests a system should pass and fail we can use tools to automate most of our tests. An automated job is one that’s always very, very easy to do. These automated tests are meant to be run every time there’s a code change and are referred to as unit tests.

Author: Muthukumar. V
Published: January 19, 2005
link

One-page quick reference guides available

01.24.2005 · Posted in News

Gunjan Doshi has created two quick reference sheets for Test-Driven Development, and has made them available to all testdriven.com users under the Download section.

[url=http://www.testdriven.com/modules/mydownloads/visit.php?cid=3&lid=4]The Test-Driven Development Quick Reference Guide (PDF)[/url] is a one-page guide providing a quick reference to several common questions. It also includes quick references to the TDD Cycle, Things to always do, and Things to never do.

[url=http://www.testdriven.com/modules/mydownloads/visit.php?cid=3&lid=3]Test-Driven Development Rhythm Reference Guide (PDF)[/url] is a one-page cheat-sheet to remind oneself of the Test-driven rhythm. The guide also suggests the approximate time that should be spent on each phase of the Test-driven rhythm.

Feedback appreciated.

The testdriven.com crew warmly thanks Gunjan for his contribution.

TDD with DDD, Design for a Mock JDBC Driver…

01.24.2005 · Posted in Blogosphere

Steve Eichert does TDD with DDD: "By separating all data operations into a repository, my test class can handle setting up all data necessary. Since this all occurs in a single test class it reduces the duplicated logic that previously appeared in a bunch of the test classes for the individual domain objects."

Mike Slattery shares his Design for a Mock JDBC Driver and asks for feedback: "I think unit tests are very important. I think having fast unit tests is important. Using mocks makes unit tests much faster. Writting JDBC mocks can be tedious and they are prone to being brittle."

Murray White (ThoughtWorks) sees [url=http://www.oetrends.com/news.php?action=view_record&idnum=393]Open Source blending with SOA, Agile Dev[/url] in 2005: "2005 will see more corporate IT shops adopting Agile processes, either in part or in whole, in reaction to the need to improve cost effectiveness, drive innovation, and deliver measurable business value in the face of volatile business requirements. "

Here’s a cartoon on poor understanding of TDD.

Alastair Patrick would like to build support for code coverage analysis into his C# to C++ translator.

Fred Grott embarks on development of a TDD Build Framework for J2ME.

Managing Projects with Maven [PDF]

01.23.2005 · Posted in Links

Maven started life as a subproject of Turbine, a Web application framework. It was born out of the need of its lead developer, Jason Van Zyl, to easily add in new pieces of functionality to his build process, such as unit testing or source metrics, both of which can be extremely important to a large project. The first iterations used Ant as the build system, but then Maven moved away from Ant to use Jelly as its primary scripting engine to build the plug-in architecture that is there today.

This book chapter is excerpted from: Professional Java Tools for Extreme Programming (Chapter 26).
link

More agile automation; Going beyond xUnit; Transparent IoC…

01.20.2005 · Posted in Blogosphere

Danny Faught and James Bach [url=http://www.stickyminds.com/sitewide.asp?ObjectId=8392&Function=DETAILBROWSE&ObjectType=COL]suggest taking a more agile approach to test automation[/url]: "If you think that test automation is mostly about executing tests, then you’re missing out on a big opportunity. Or rather, you’re missing a lot of small opportunities adding up to a big one. Consider this: stop thinking about test automation as merely executing automated tests, stop thinking about test automation as something you need expensive tools for, and start discovering automation you can implement in a couple of days and usually with extremely inexpensive tools or tools you already have available."

Kevin Dangoor moves beyond xUnit for testing: "py.test has some nice features that attracted my interest immediately and really make up for the fact that it’s not running in an IDE with a nice green/red bar. py.test has nothing for you to subclass. It will hunt down modules, functions and methods that start with test and run those."

Eugene Kuleshov shows how to gain complete control on coverage data flushing from a Clover build process, using a remote call to J2EE container JVM that will force Clover to flush coverage data.Franck Carver can’t read a bowling scorecard, and uses this example to show lacking domain knowledge impairs one’s ability to test-drive code: "I’ve played 10-pin bowling maybe twice in my life, and the scoring was always done by a machine. When it showed my initials on the screen I threw the ball. When it showed someone else’s, they had a go. At the end we went and got a printout with a series of strange symbols and abbreviations followed by a final score to tell us how many points everyone else had beaten me by. I simply don’t have enough domain knowledge to construct sensible tests, and therefore cannot solve this problem using TDD."

Paul Wilson has a nice report on XP Day 2004. (slightly dated)

Keith Ray nicely explains TDD and argues it’s faster.

Steve Hayes addresses the pros and cons of [url=http://www.builderau.com.au/program/0,39024614,39173564,00.htm]Pair programming[/url].

Dave Thomas shows how to craft Transparent Inversion of Control.

Michael Stal demonstrates unit-testing in C# with the Factorial example.

Thomas Weiss continues a series of weblog entries casting the spotlight on ABAP Unit (part one, two, three, four). See also Stepan Smarin’s short introduction to TDD with ABAP.

Tim Bray describes how you can waste time by doing your unit testing just slightly wrong and now uses exceptions to remember unimplemented stubs.

Sara Ford asks What software testing topics you want to hear more about.

Sean McCormack decides to [url=http://www.adapdev.com/blogs/smccormack/PermaLink,guid,70e150d2-b5a9-490e-9484-4d86d6271e2f.aspx]release Codus as Freeware[/url]. Codus is a comprehensive code generation tool for object-relational mapping which generates unit tests for the code produced.

JetBrains has opened an Early Access Program for version 1.5 of ReSharper. Tim Haines compares ReSharper, CodeRush, and Refactor.

Paul M. Jones decides to do Unit Testing development of Savant3 in replacement for eyeball tests. Ensuing comments discuss the pros and cons of several unit-testing frameworks for PHP.

On the fun side, Paul Ballard predicts the oncoming of a new methodology, Development Driven QA: "Test Driven Development will continue to gain popularity amongst developers as more and more of them take to writing unit test scripts. In an interesting twist, QA engineers will determine that the best way to test these scripts is to write the actual components starting a new movement called Development Driven QA."

And Lasse Koskela thinks sobriety is an agile principle.

Changing Software and Legacy Code

01.20.2005 · Posted in Links

The old adage, "If it ain’t broke, don’t fix it," doesn’t necessarily apply in the case of technology. Projects continually require alterations, updates, and enhancements. This chapter outlines the nature of code change, and suggests some of the challenges to be faced when making these changes.

Author: Michael Feathers
Published: InformIT, January 14, 2005
Excerpted from Working Effectively with Legacy Code
link

Working Effectively with Legacy Code

01.20.2005 · Posted in Links

Working Effectively with Legacy CodeGet more out of your legacy systems: more performance, functionality, reliability, and manageability

Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.

In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy systems under control.

The topics covered include

– Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance
– Getting legacy code into a test harness
– Writing tests that protect you against introducing new problems
– Techniques that can be used with any language or platform—with examples in Java, C++, C, and C#
– Accurately identifying where code changes need to be made
– Coping with legacy systems that aren’t object-oriented
– Handling applications that don’t seem to have any structure

This book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.

Author: Michael Feathers
Published: Prentice Hall PTR, September 22, 2004
Excerpt: Chapter 1: Changing Software and Legacy Code
link

Tags: ,

Putting applications to the test

01.20.2005 · Posted in Links

Application testing is traveling down the same path that has lately been followed by IT security. A combination of heightened awareness and regulatory mandates has transformed security from a "why fix the roof when it’s not raining?" cost to a recognized requirement of due diligence.

Application testing efforts may likewise obtain improved access to human and technical resources, and development team leaders may encounter fewer arguments when they seek to acquire state-of-the-art tools as the costs of application failure grow.

Author: Peter Coffee
Published: January 17, 2005
link

Tags:

The Daemon Inside

01.20.2005 · Posted in Links

We need to build another model – a slightly different way of thinking about our software – to help us deal with async behaviour, and it must take account of the fact that the systems we build are too complex for mortals like me to completely comprehend.

To put it another way, we’ve got to find a way of simplifying things so I can cope with my life.

I’m going to assume we’re using a test-first(-ish), OO-ish implementation model; i.e. we create a lot of unit tests for a lot of classes; and we don’t want to lose all of that goodness. We want to build on it and adapt it to the multithreaded scenario, while maintaining its fundamental characteristics.

The main strategy is to narrow things down to a single point of view – we only ever look at what’s going on in a single thread of execution. We treat each thread as a separate owner of responsibility, and while we implement or debug we don’t worry what other threads of operation running concurrently are actually doing, just what they could be doing. By Murphy’s Law, the tendency will be that they are doing it, and that’s what’s going to screw us up.

I like to think about the evil little daemon. He’s been sent from whichever mythological domain you prefer, and he executes every line of code precisely according to the specification, and yet looking for every opportunity to make things fail.

This has implications for our test strategy.

Author: Andrew Cain
Published: January 16, 2005
link

Tags:

Nantpad: NAnt build script authoring tool

01.20.2005 · Posted in Links

Nantpad was designed to make authoring, browsing and executing scripts for the popular process-automating tool NAnt, quick and straightforward. [url=http://www.testdriven.com/search.php?query=nant&action=results]NAnt[/url] is used widely in the .NET environment for automating the build process of software projects. The authors of Nantpad understand that writing and maintaining XML NAnt scripts by hand is not an easy task, especially for larger projects. Nantpad takes the hassle of NAnt by allowing the developer to take control of their automated processes with the sophisticated features of this user-friendly tool.

(commercial tool)
link

BeetleJuice Continuous Integration Server

01.20.2005 · Posted in Links

Beetlejuice monitors your source code repository and triggers a build whenever the source code changes. It sends an email whenever the build fails. This ensures a controlled build process that provides rapid feedback whenever there is a problem. The more your developers integrate the code the better. Beetlejuice makes this a safe and easy process.
link