Does Extreme Programming Need Diagramming Tools?

Question

I have been experimenting with some concepts from XP, like the following:

1. Pair Programming
2. Test First Programming
3. Incremental Deliveries
4. Ruthless Refactoring

So far so good until I had a major stump:

How do I design my test cases when there aren't any code yet? From what basis do I have to design them? From simple assumptions? From the initial requirements?

Or is this where UML diagrams and the "analysis phase" fits in?

Just had to ask because in some XP books I've read, there was little to no discussion of any diagramming tool (there was one which suggested I come up with pseudocodes and some sort of a flowchart...but it did not help me in writing my tests)

Answer 1

How do I design my test cases when there aren't any code yet? From what basis do I have to design them? From simple assumptions? From the initial requirements?

To write a test you don't need any code. You know your inputs and you know your expected outputs. So you can design a test case to implement it.

I don't see any tight relationship between UML stuff and XP. UML is for design the software and XP is the process you follow to develop that software. So please clarify the question if possible.

Answer 2

Agile processes are often paper-based, but this makes some basic assumptions that might not be true in a corporate environment.

Even if your team is distributed you can still use pens and paper (with a color scanner) or a white board (with a cheap digital camera). Capturing the images this way can be more agile than trying to use more specialized software tools because you tend to focus on solving the problem, rather than driving the tool, or tweaking the visual presentation.

How do I design my test cases when there aren't any code yet? From what basis do I have to design them? From simple assumptions? From the initial requirements?

You start from the user story informed by the initial requirements and discussions with the "on-site customer" if you're lucky enough to have one.

The idea is that you write the test before the code, so that you know when you've finished. The code might not run correctly, or even compile, from the point that you start writing the test until the point where the test runs and passes. This is similar to traditional "test last" development, except that the time that the code is broken tends to be shorter, and you're guaranteed to have a test at the end.

It changes the way that development is motivated from "What code shall I write next?" to "What test shall I write next?". The second question is easier to answer as long as you have a basic idea of what it is that you want to do.

Answer 3

The test cases come from the initial requirements. They specify what you're going to build, so where else would the tests come from?

One technique you might find helpful is to take a feature and break it down into three elements: Given, When, Then. Given is the initial data, When is the program call, Then is the desired outcome. The point being, any requirement you cannot analyse like this may not be correct, or at least needs further details.

The Google testing team are very fond of this approach and have blogged extensively about it. Find out more.

Answer 4

XP has no "analysis phases".

You don't need to use a diagramming tool with XP, although there's nothing to stop you if you choose to use one.

What do you want to model?

It sounds like you want to describe the problem domain (i.e. modelling for analysis) rather than documenting the implementation. XP doesn't work like conventional methods where one specialist does "analysis" and another does "coding". In XP it's likely that the analyst is a developer working with somebody in the business working together to break down user stories and estimate them.

You typically don't start out documenting test cases - we write automated tests in code, either in code or in an executable specification such as with JBehave or cucumber. It's about as much effort as diagramming them but with a much better return on investment.