[TIP] Behavior Driven Development (was TDD)

[Nate Lowrie]

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
>