Coding Is Like Cooking

At agile2008 I attended a session with Dan North about Behaviour Driven Development. Someone on the agile sweden mailing list was asking about it, so I decided to write up my notes here.

Most cellphone and computer software is delivered late and over budget. The biggest contributing factor to cost bloat is building the wrong thing. So what software and business people need is “a shared understanding of what done looks like”.

Test Driven Development is about design, conversations, and writing examples for a system that doesn’t yet exist. It’s not really about testing. However, once the system exists, your examples turn into tests, as a rather useful side effect.

A User Story is a promise of a conversation, and it is in that conversation that things go wrong. The customer and developer rarely agree what “enough” and “done” look like, which leads to over- or under- engineering.

Dan suggests a format for User Story cards which aims to prevent this communication gap.

On the front of the User Story index card, you have the title and narrative. The narrative consists of a sentence in this format:

As a stakeholder
I want feature
so that benefit

where benefit is something of value to stakeholder.

On the back of the card, you have a table with three columns

Given this context | When I do this | then this happens

Then you have 4 or 5 rows in the table, each detailing a scenario. (If you need more than that then the story is too big and should be split)

Dan finds that in his work, this leads to conversations about User Stories where “done” and “enough” are discussed, and defined.

User Stories should be about activities, not features. In order to check that your User Story is an activity, you should be able to do a thought experiment where you implement the story as a task to be performed by people on rollerblades with paper. You must think about it as a business process, not a piece of software.

When creating the story cards, the whole team should be involved, but it is primarily the business/end user stakeholders and business analysts who write the title and narrative on the cards. They then take in a tester to help them to write the scenarios.

Are people familiar with the V model of software testing? When this was conceived, they thought that the whole process would take 2 years, and span the whole project. Dan ususally does it in 2 days. Many times for each project.

Then Dan offered to show us how to do BDD using plain JUnit. He requested a pair from the audience, so I volunteered. At this point my notes dry up, and I am working from memory, but I think the general idea is like this.

You talk about “behaviour specs” not tests. The words you use influence the way you think, and “behaviour specification” gives much better associations than “tests”.

Each behaviour specification should be named to indicate the behavour it is specifying. Not “testCustomerAccountEmpty” rather “customerAccountShouldBeEmpty”.

In the body of the spec, you can start out by typing in the prose of one of the scenarios you have on the user story, as a comment.

//given we have a flimble containing a schmooz
// when we request the next available frooble
// then we are given a half baked frooble and the schmooz.

Then you can fill in code after the “given” comment. When you have code that does what the comment says, delete the comment. Repeat with the “when” and “then” comments.

In this way, you build up a behaviour specification that drives your development of the system. A few minutes later (hopefully) you have a system which implements the specification, and at that point your spec helpfully turns magically into a regression test which you can run. At that point you can start calling it a test if you like. But actually it is more helpful to your brain to continue to think of it as a behaviour specification. It leads to much more constructive conversations about the system.

Test Driven Development (TDD) is a way of programming where you start be specifying a (failing) test, write code until it passes, then refactor. Repeat. This technique has been hugely valuable and adopted widely since it was introduced to the world by Kent Beck and others. The classic way to perform TDD is to specify the tests using the same programming language as the code under test, with the help of a little framework called xUnit. (Replace “x” with the language of choice). But how would TDD look if you used another tool instead of xUnit? Is there a way of capturing the advantages of the approach, but using tests that are easier to write and maintain?

About TDD with TextTest

I begain using xUnit in 2000 and have been improving my skill at TDD ever since. Recently though I have been working less and less with xUnit tests, and more and more with using TextTest tests to drive development. This approach seems to preserve the original spirit of TDD, ie the tests are still driving development, but there are some differences and advantages.

When you use TextTest to drive development, your tests all end up being written in a representation that is separate from your code, ie a kind of Domain Specific Language (DSL). Your tests can be read and understood by anybody who understands the domain of the system under test, that is, they don’t have to be able to read or write program code. You typically don’t write new code when you write a new test, you just specify new desired program behaviour using this DSL. This makes it quick to add new tests, and easy to refactor your code later, since the test doesn’t place any demands on the internal structure of your program (its classes and methods).

With xUnit tests, each test is only working with a small section of code, whereas a TextTest typically drives a path through a whole system or subsystem. This means that you need to use another technique to get fine grained visibility of what your code is doing. Instead of turning to a debugger, the approach with TextTest is to include log statements as you code. Having your application write a log is not a new idea and there are a number of excellent logging frameworks out there. TextTest allows you to not only specify the behaviour of your application in terms your customer will understand, but also control the application logging behaviour. When you make a code change, and your program no longer behaves the way the customer wants, (you introduce a bug), you can turn to the recorded application log to pinpoint exactly where program behaviour deviates from that previously recorded. So a test case consists basically of program input, expected user-readable output, and an application log.

TDD with xUnit is also generally accepted to be a design technique as well as a testing technique. I think there are two reasons for this. Firstly, just the fact of having these tests in some sense forces you to make good low level design decisions. Your code must exhibit loose coupling and high cohesion before you can extract units of code to test. This is desirable, and TextTest does not force you to do it, since it tests at a higher level of granularity. (On the other hand, if you are starting with poorly structured legacy code, where easily extractable units are hard to come by, you can get going with TextTest more or less immediately just by adding some (hopefully) harmless log statements. But I am not talking about legacy code in this article).

The second way in which TDD affects your design is that it forces you to think about the interface to your class before you define the implementation. This is low level design – choice of class and method names, and what arguments you give them. This is useful because thinking about the interface before the implementation should lead to a better, cleaner interface that is easier to use. TextTest doesn’t help much with this either. It will force you to start by defining the interface to your whole program or subsystem, but it won’t help on the class level. So when developing with TextTest we suggest something called “usage first” design. Start with the external interface to your program, and write code as if the classes and methods you want are already there. Then fill in the implementations, always working top down, and defining the usage of a class or method before your implement it. This takes some discipline, but leads to a similar effect to using xUnit.

About Code Katas

A code Kata is an idea introduced by Dave (Pragmatic) Thomas. He points out that specialists in other disciplines do a lot more practicing than programmers do, in order to improve their skills. Others have further developed this concept into the idea of a “Coding dojo”, or a place where programmers meet to practice code Kata together. The website www.codingdojo.org is a resource for these communities, and amongst other things has a catalogue of various code Kata exercises various individuals and groups have worked on.

About the KataMinesweeper screencast

So that is all the theory, how does it work in practice? In this screencast, I demonstrate a PreparedKata of KataMinesweeper, using TextTest to drive development, in python. During development, I aim to work in a Test Driven manner, and I want to develop top down, usage first, in small steps. The idea is that although in real life you may not be so strictly test driven, or exclusively top down, or use such small steps, that it is important to know how to do these things, and they are worth practicing on a toy problem like this.

My aim is to demonstrate what it is like to do TDD with TextTest, and how you might solve this code Kata using the python programming language. If you would like to comment and give me constructive feedback on this screencast, I would love to hear from you.

The screencast is in four parts, and I estimate each part will take you about 10 – 15 minutes to view.

• KataMinesweeperPart1

• KataMinesweeperPart2

• KataMinesweeperPart3

• KataMinesweeperPart4

(Note: This screencast was created using Wink. In it I use Windows Vista Home Edition, Easy Eclipse for LAMP version 1.2.2 and TextTest version 3.9.1.)

At the XP2007 conference, Geoff and I presented a workshop entitled “The coder’s dojo: Acceptance Test Driven Development in python”. (Geoff also presented the same workshop at agile2007). We had three aims with this workshop, the first was to use the meeting format of a coders dojo, the second was to do some coding in python and the third was to demonstrate how you can do Acceptance TestDriven Development using TextTest. We felt the workshop went well, we had around 30 participants and we were able to do a little of everything we had set out to do.

Perhaps the most important thing was what we learnt from the experience. The workshop participants gave us some very useful feedback. One thing people said was that there were too many new ideas presented to expect as much audience participation as we did, and that instead of trying to do aRandori style kata, we should have done it as a Prepared kata. There also seemed to be a view that the Kata we had chosen (KataTexasHoldEm) was quite a difficult one. Another very valuable piece of feedback was that we were doing Test Driven Development (TDD) with much larger steps than people were used to.

What I have done is to create a screencast in an attempt to address this feedback, and open up our workshop material to a larger audience. In it, I perform a Prepared Kata of KataMinesweeper, doing TDD with TextTest and python. Geoff and I have been developing this approach to testing for a few years now, and we think it deserves consideration by the wider agile testing community. There are important advantages and disadvantages compared to classic TDD with xUnit.

I will write an article about this approach and provide links to the screencast in my next post on this blog.

I mentioned in a previous post that we were planning to attempt KataMinesweeper at a GRUG meeting. That meeting actually happened on 19th September so I am a bit late reporting on it, but never mind. There is a summary of what we did here.

I had never really seen RSpec or Behaviour Driven Development (BDD) before and I was quite fascinated by it. It’s basically Test Driven Development but with different words for everything, and much more human readable tests, or “examples” as they are known.

One of the other challenges we faced at this meeting was that we were developing on a Mac, which is an unfamiliar environment for most of us. There was one participant, Håkan, who was particularly fased by this. He obviously usually touch types on Windows and is very familiar with that keyboard layout. He persistently kept hitting what his fingers thought was the “home” key, that on this Mac had the effect of making all the code disappear from the screen. He must have done it a dozen times in five minutes, which was very frustrating for both him and us.

I thought it was a good analogy for how I felt faced with RSpec, when I have been working with xUnit for so many years. I must have said “let’s run the tests now” or “that test is failing because…” a dozen times. In BDD they are not tests they are examples! By about the 5th time I said it people just got fed up with correcting me.

So it seems to me that if Håkan wants to start writing code on a Mac regularly, he’s in for a frustrating time while he teaches his subconcious new habits. Likewise if I am going to learn BDD. The question is, is it worth the effort?

For Håkan, my immediate reaction is that learning a Mac keyboard wouldn’t be worth it for him. I don’t see the Mac keyboard as giving any great leap in productivity over a Windows keyboard, so the cost of switching would be prohibitive.

The potential benefit for me to switch from TDD to BDD is less clear to me. Would this change in language actually significantly improve the way I do software development? For the moment I plan to keep an open mind on the subject.

I was really impressed by this screencast that Thomas Nilsson did of him solving KataBowling. Quite apart from the skill with which he solves the programming problem, I like the format. I have previously tried to describe how I have solved other Kata, by writing long articles on codingdojo.org, like KataPotterByEmilyBache, but these articles are much harder to digest than this screencast Thomas has put together.

I have found out that he used a piece of software called wink to create the screencast, so I am currently working on one of my own. Watch this space!