program selection system

It’s easy to speak of test-driven development as if it were a single method, but there are several ways to approach it. In our experience, different approaches lead to quite different solutions.

In this workshop, we’re not trying to decide which approach is best. Rather, we’ll use concrete examples to explore

• What goes into the moment of decision when a test is written?
• How do you think about the problem you’re trying to solve?
• What strategies or techniques help you write the first few tests?

Abstract

Over the last few years we have had the good fortune to aggressively apply the agile practices on a number of projects with great success. These successes, however, have not been achieved without challenges and lessons learnt along the way. This experience report specifically highlights examples from three different software development projects of varying sizes within this period and within the same organization. This is the story of three little pigs, where in all cases the pigs were well and truly committed.

FIT is a framework that comes in various guises (Fit, Fitnesse, Fitlibrary), and can be used in different ways. The core principle behind writing FIT documents is to promote better communication between the stakeholders of a system. In principle, using FIT is a good thing, but in practice we find that some teams struggle to use FIT documents effectively. In this tutorial we will introduce some concrete examples of poor FIT style, and get the participants to refactor these examples to improve them.

By attending this session, you will:

Projects that fail do so mostly because they build the wrong thing, not because they do a bad job building whatever they do build. A big part of the difficulty is getting the users to tell us what they want. Traditional requirements engineering approaches have had mixed results, but requirements capture through “checked examples” (eg Fit -style tests) seems to work very well. Why should that be? Are there clues to be had from post-Aristotelian notions of “category” in the cognitive sciences? If so, how can that help find better examples?

This is a follow-on from a reasonably well-received talk given at Agile 07.

The session will be a work-torial. Or possibly tut-shop.