fredag 5. februar 2010

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.

Ingen kommentarer:

Legg inn en kommentar