Scott or Amundsen, who would you follow?

It is obvious, Scott died, Amundsen did not. What can we learn from an expedition like the journey to the South Pole?

Scott went for the "best" equipment (motors, dogs, horses), but failed. Amundsen used dogs and they wore clothes made of sealskin. On Amundsen's trip through the Northwest passage he learned from the local Netsilik people about arctic survival skills that proved very useful on the expedition to Antarctic.

In software development you must know your problem domain before you develop and finally go into deployment. This is what Amundsen did, he learned from domain experts, and this is what developers should do. Investigate the problem domain and write tests. When you know the domain well you will have a good base for writing tests. This will make your application safe and stable.

Another thing I like about mountaineers is that they practice a lot before they go for the real expedition. Like Tormod Granheim, who skied down from Mount Everest. He skied down a lot of other safer mountains before Mount Everest. Testing your application thorough, and close to the real environment, will make it stand a real situation.

Metaphors for software development are useful, but they will not be a complete analogy. Anyway, I like the mountaineering approach.

What does it take to do test first?

I am starting my task and the problem is, I do not know what test to write? So what should one do to follow a good principle to write the test first?

• Investigate the problem domain. Talk to your customer, talk to an expert in the field you are dealing with. What assumptions can you make? What conditions can you set? What goes in, and what comes out? Write user stories and prefer a pattern like "As a <type of user>, I want <some goal> so that <some reason>".

• At least write one acceptance test. Return later and write more acceptance tests. Prefer a pattern like "Given, When, Then".

• Write some quick code to investigate what your acceptance tests assume. A console application or just an integration test will do. If you need test-data, retrieve some.

• Write one, and only one, unit test. What states can you check? What behaviour can you test? Make it pass. Write another unit test...... now you are into TDD.

I believe many hesitate to go for TDD just because they do not know what tests to write. You hear Uncle Bob do his preaches of test first, but as anything else you learn, things usually are not black or white.

Knowing your problem domain gets you going to think about what you want to test. I believe this is starting designing: "...we need to really understand the problem space and find a solution... And also that it is a continuous process that will drive software development throughout the whole lifetime of the project.", Mark Nijhof.

Writing acceptance tests first makes you think about what you have to assume? What are the conditions? This is also a good start to document your work, which someone will be interested in. And it is good to have a customer agree with you, and to confirm your assumptions and conditions.

When you have come this far, you are beginning the most fun thing: Write code and make it pass your unit tests. And now you are 100% productive.

This is just one of my experiences starting TDD. I have tried to summarize it, rather then go into long details.