[TIP] Behavior Driven Development (was TDD)

Grig Gheorghiu grig at gheorghiu.net
Mon Mar 5 11:23:12 PST 2007


--- Kumar McMillan <kumar.mcmillan at gmail.com> wrote:

> sorry for the confusion.  I'm no expert on BDD.  And yes, after
> re-reading their site, http://behaviour-driven.org/ , they do advise
> making mock objects for all dependencies.  I just thought that was
> because the examples were in java :)  Like a few people pointed out,
> this is dangerous because the more mocking you do the farther away
> you
> get from the "production" environment.

Here's a BDD-style patch to unittest that Michal Kwiatkowski came up
with. In fact, he has a nose plugin for it that will be released soon:

http://mousebender.wordpress.com/2007/02/14/make-your-tests-self-documenting/

I don't really buy into all this 'BDD is vastly superior to TDD'
argument. I think you can achieve many of the BDD goals by proper
naming of your unit test methods/functions.

> 
> Also, if you write the unit tests first then you are 1) introducing
> potentially unnecessary maintenance (if the units you need changes)
> and 2) you are distracting yourself from the problem at hand -- the
> set of requirements that are requested of your software by the
> business.

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.

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).

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.

I think Bob Martin from Object Mentor said 'Unit tests help you write
the code right. Acceptance tests help you write the right code'. They
each have their place, and I recommend having generous servings of
both. As a programmer, you can shape your code so that it achieves what
the acceptance tests say it needs to achieve. But the way you shape it
is by writing unit tests.

Grig




More information about the testing-in-python mailing list