[TIP] Behavior Driven Development (was TDD)

[Michael Foord]

Grig Gheorghiu wrote:
> [snip..]
> What I saw happening in other companies is that if you write your
> acceptance tests first and make them too detailed, the
> requirements/stories can change so much during an iteration (assuming
> you're doing XP-style development), that you need to constantly change
> your tests. 
>
> So I would start with some broad acceptance tests in the form of
> stories (and those stories can be 'executable documentation' if you use
> Fitnesse or doctest), and then drill down into more detailed testing at
> the unit level. Once the stories stabilize, go back and shore up your
> acceptance tests with your newly-found knowledge of what to expect and
> when.
>
>   
I think that acceptance tests using doctests are a good approach. I 
guess I've been reconsidering my position on that. Not that it was a big 
deal, but that approach does seem to fit nicely.

> The way I see it, unit testing is more useful to programmers, and is
> the only way I know that allows them to comfortably refactor their
> code. Without unit tests, they have no safety net. Also, unit tests are
> usually much faster than end-to-end acceptance tests, so they can be
> ideally executed upon each and every check-in by the continuous
> integration system (and before the check-in by each developer).
>
>   
+lots

Good unit tests are an astonishingly powerful programmers tool.

> Acceptance tests are more useful for testers and business analysts (or
> customers as XP calls them). They can take much longer to run, so
> they're typically run every night -- definitely less frequently than
> unit tests.
>
>   
Well, we've found our acceptance tests do catch occasional bugs and 
breakages that unit tests miss. I wouldn't dismiss them as not-useful 
for programmers.

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml