Red Bar Time

or, "How I learned to stop worrying and love the red bar"

This is a term that you'll hear (or ones like it, "red mode" etc) in various places around at least the UK XP community, probably others, too. It simply means, the time during which StarUnit reports failing tests. This is a good thing.

The ExtremeProgramming unit testing practice is often stated in one line as something like: have all the unit tests pass all the time. But that can't possibly be right, since it would prevent TestDrivenDevelopment?. We need some red-bar time in there.

Red-bar time is, by definition, the only time during which the capabilities of a codebase can be extended to meet the need to pass more tests. And more tests means more functionality, higher quality, more motherhood and apple pie. Compare with "green-bar time", during which all that can occur is refactoring (a good and worthwhile thing, of course).

What can we infer from a green bar? Mainly that we don't have enough tests yet. Since XP aims to get a product into the maintenance part of its lifecycle as quickly as possible, it's always a little worrying when the green bar is up. It suggests a spurious air of completion. The red bar, on the other hand, indicates progress being made. When new functionality is being added, the green bar almost never means what it is often claimed to, that we are "done". We're only "done" the day the product is end-of-lifed. And then how are we going to pay the rent?

In fact, I'd claim that during a development episode we need to have the largest total amount of red bar time possible, but the shortest possible duration of each run of red time. Any time you see the green bar, by God write a new failing test as quickly as you can.

Of course, making the new test pass might involve inadvertantly breaking some other test, thus extending the red-bar time. But that's OK, because it's the code telling you that it isn't how it needs to be to meet the new requirement and all the other current ones. It's a pointer to a much-needed design improvement. And often the newly failing test will tell you exactly what improvement is needed and where. This too is a good thing, and a big part of the magic of red-bar time.

What can we learn about our codebase during green-bar time? Merely what it is prepared to put up with, not what it wants.

"when the bar is green the code is clean". Well, yes. For sufficiently small values of "clean".

When the bar is red, we're forging ahead. --KeithBraithwaite.

Well said! I like having failing unit tests as my ToDoList, because I can handle the RedBar. Some might consider it having many balls in the air at once, but my contention is that those balls are already in the air - I just want to be able to count them and know where they are. -- JohnFarrell

CategoryTime