[TIP] Behavior Driven Development (was TDD)
fuzzyman at voidspace.org.uk
Mon Mar 5 14:46:47 PST 2007
Grig Gheorghiu wrote:
> 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
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).
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
All the best,
More information about the testing-in-python