[TIP] Behavior Driven Development (was TDD)

[Kumar McMillan]

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.

But the key concept is what I'm after : that you are developing
software for a specific business entity to gain some quantifiable
value from, so write your tests at that level.  At least the bulk of
your tests.

The desired "behavior" gets written up in user stories (as the
examples on the BDD site suggest) and you write your tests around
fulfilling the objective of the story.

As far as maintainability, consider this.  When writing tests at a
very high level you are testing for these "requirements."  When the
requirements change, your tests need to change to reflect the new
behavior you are testing for.  But if you want to implement the
requirements differently (faster, slimmer code, i.e. refactored) then
you shouldn't have to change your tests!  This is all I'm trying to
get at.

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.

Granted, not all development works in this way: providing business
value.  This is just the way my company works.  On a side note,
FITnesse pretty much calls for this same approach through acceptance
testing but I have dug into that yet.

On 3/5/07, Nate Lowrie <solodex2151 at gmail.com> wrote:
> Ok, I guess that I am a little confused here.  I have always thought
> that behavior driven development was using Mocks and behavior
> verification in place of state verification.
>
> I understand where you are coming from with the outside-in concept.  I
> need to do more of that myself.  However, I thought that outside-in
> development was simply writing acceptance tests first, and the working
> your way down to integration and unit test levels.  While this has
> merit, I think that it tends to introduce much more refactoring than
> writing unit tests first especially if same developers aren't familiar
> with things like layered architecture and dependency injection.
>
> TDD and BDD are closely coupled with design patterns and I find that
> few developers know of or exercise these patterns.  I have seen new
> developers try to do TDD and fail precisely because in order to write
> efficient unit tests you are required to exercise good design and
> design patterns.  I don't think that the fact they are writing unit
> tests before integration tests has much to do with it other than that
> unit test require you to have a mental layout of the architecture in
> mind already.
>
> Just my thoughts.
>
> Cheers,
>
> Nate L.
>
>
> On 3/5/07, Kumar McMillan <kumar.mcmillan at gmail.com> wrote:
> > On 3/3/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> > > I'm interested in how many people on this list are doing test driven
> > > development ?
> >
> > slightly late to the conversation, but my practice is slightly
> > different than what most people have written and I thought I'd kick it
> > into a new subject.
> >
> > When first begining a project I find that it slows me down if I try to
> > automate the tests.  I get much more momentum by writing some very
> > basic exploratory code and manually testing the results.  This stage
> > usually doesn't last too long since as soon as I have a direction, I
> > write a test to prove that the desired requirements are met.
> >
> > From that point on I almost always test first, writing a test at the
> > the highest level possible (i.e. load a web page, run a script,
> > doctest) and then follow up with the implementation to pass the test.
> > I like to work my way down to the unit level prudently since once you
> > get down to testing the unit you have a lot more maintenance to do if
> > you want to change the implementation that passes your high-level
> > test.
> >
> > When I've worked with developers who've struggled with test-driven
> > development I've noticed it's generally because they are trying to
> > start testing at a very low level, the unit test.  I think this is a
> > hard place to start because the problem you are trying to solve is
> > staring you in the face (the web page, the xml files you need to
> > parse) and the idea of solving that with several units of code is an
> > unimportant detail.  Testing helps you understand the interface, not
> > the implementation, so starting at a small level seems
> > counter-intuitive to me.  Thus, I would suggest to anyone who
> > struggles with test driven development to try testing from the
> > "outside", testing the interface first, before it works.
> >
> > There are a couple tools for this -- twill [1], PyFIT [2], fixture [3]
> > come to mind -- but it's really just a concept.  There is a ruby
> > module that tries to encapsulate this concept which is sort of
> > interesting: http://rspec.rubyforge.org/ .  They call this "behavior
> > driven development" which also makes a little more sense.  However,
> > Ian Bicking wisely pointed out that doctest is a very fine example of
> > doing behavior driven development in python :
> > http://blog.ianbicking.org/behavior-driven-programming.html
> >
> > [1] http://twill.idyll.org/
> > [2] http://agiletesting.blogspot.com/2004/11/writing-fitnesse-tests-in-python.html
> > [3] http://code.google.com/p/fixture/
> >
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
> >
>