AGILE IN ACTION

Here's a nice TDD taster from Steve Freeman. And something on the use of mock objects.

Kent Beck replied:

Rick Mugridge talks about story test-driven development using FIT and doubling the value of automated tests . Story tests, written in FIT, capture the details of user stories as concrete executable examples and help you to know when you're done. These video presentations are not technical tutorials on how to use FIT / FITLibrary / FitNesse .

It's worth being test-driven and working from the outside-in, starting with automated acceptance tests. And it's worth getting done in the iteration, which means performing any supplementary testing, e.g. adhoc testing on a per user-story basis in the iteration. This means that testing responsibilities and skills are an intrinsic part of the team and are colocated.

Ten-minute build It's worth developing an automated, reliable and reproducible build for your project that builds the system and runs all the tests. It should be run many times a day, initiated by a schedule or in response to some asynchronous event such as checking source code into the repository. You should also be able to initiate the build on demand, e.g. from the command line or from within an IDE. The build needs to be fast if it's going to run frequently. Therefore, you need to invest in continual improvement and optimisation to maintain a ten-minute build cycle. Any longer than ten minutes and the build won't be used as often and won't provide as much feedback. Continuous integration Traditional integration is a big-bang affair, highly unpredictable and typically fraught with problems. A build that runs frequently allows developers to integrate and test their changes often, perhaps every 2 to 3 hours. There's no rule of thumb here; it depends on your code and how you've broken the functionality down into chunks to be developed, but the longer you wait to integrate, the more risky and unpredictable integration becomes. By integrating often, integration is broken down into many small integrations that are performed as part of the cycle: test-code-refactor~~integrate . The integration nightmare goes away and the number of integration problems are reduced. A continuous integration tool like Cruisecontrol can be configured to start the build asynchronously, triggered by a check-in of source code to the repository. If problems are encountered during the build, which includes running all the tests, the developers are automatically notified by email, RSS, or a text message (also take a look at some alternative extreme feedback devices ). The rule here is to react immediately and fix the build. A broken build should not be tolerated. Developer rhythm A ten-minute build automated with continuous integration helps developers establish a rhythm as they develop software. This rhythm reminds developers to integrate regularly. Integration should happen at least once a day and only working tested code should be checked-in. Source code should not be checked-out for days on end, and broken code should never be checked-in. The following diagram shows the steps a developer performs in the test-code-refactor~~integrate cycle. developerrhythm Originally uploaded by sjb140470 I always do a local clean build before I commit any changes to the repository. With a ten-minute build I don't have to wait long before I know whether I can proceed with the check-in. This time gives me a chance to come up for air , grab a drink, or reflect with my pair-programming partner on the work we just completed. If you don't do a local build you'll know about any integration errors as soon as the continuous integration build runs. You can then assess the problem and decide whether a quick fix can be found or whether the changes need to be backed-out of the repository, so that the builds works once again. Continuous integration tools: Cruisecontrol , Beetlejuice , Continuum

It takes time to become proficient at test driven development. But it's worth the investment. I'm not convinced it makes writing code faster because, after all, it does require you to write more code for the unit tests. However, I am convinced it makes writing production-ready code faster.

Kent Beck talks about Extreme Programming and quality assurance.

I didn't make the haiku session at XPDAY5, but I thought I'd try it on test-driven development:

In their Guidelines for Test-Driven Development, Microsoft says: