I got an
email from a colleague a couple of weeks back. We were members of the
same team for awhile this last autumn. He (and the rest of the team) are
great programmers - way better than me. I had some difficulties to keep
in step with them, but to some extent that had to do with
F# being the language of choice. A first for me!
We had a lot of discussions about
TDD and if it’s feasible or pay off. This project
made me realize that TDD done backwards (writing unit tests after the
production code) is not only NOT TDD but also doesn’t pay off. But as I
am dunked deeply in the BDD pool I suggested that we’ve take a look at
that and get started that way. I never got through there…
So I was very happy when he wrote me an email with a link to an article that talk about doing BDD with
SpecFlow and
White. The
question was simply; Is this how BDD is done?
This was a temptation that I couldn’t resist… I thought I’ll drop the
answer in here too.
“Dear anonymous colleague,
Firstly that article talks a lot about tools
(SpecFlow,
NUnit and White in
this case) and they are all great tools and I think he sketchs out a
good process as well. But here’s the thing - BDD is not about tools!
I’ll say that last part again; BDD is a communication tool and is not
about the tools.
Oh the obsession of tools in our business! So many wrong turns we take
because of that. We so quickly want to jump to How to do stuff without
knowing much about What to do and not caring at all about Why we are
doing it in the first place.
There is really no reason to use
Gherkin and tools
like
SpecFlow if the
only one that cares is developers. If it's only developers that is going
to write, read and understand the scenarios you are probably better off
using NUnit straight up. Talk to devs in dev speak - code!
Gherkin and SpecFlow is used to discuss, experiment and clear
out misunderstandings and things that are unclear earlier in the process
than you traditionally do. You talk in concrete terms about the systems
functionality before you've written any code.
That said the tools have it's place - a win is that you can use the
scenario (to talk Gherkin syntax) and execute it against the system.
That gives you both a clear specification, a test of the functionality
and a definition of done for development. You only have to fulfill the
scenario - code to that works. That is enough. For now.
The test ability can also be used to catch regression problems and make
sure that as we developing new features we don't break stuff that used
to work.
Finally will the scenario describe how the system ACTUALLY works. It's a
great, living documentation. Compare that to any written documentation
that describes how the system SHOULD work.
Reminds me of a story when I got the documentation for a system I was
going to code against. The developer (may his name go unknown through
this story) was super proud over the quality of the system
documentation;
> Marcus - this documentation is really really up to date. It's almost
> exactly what the system actually does...
And it was great. I'd say that 97% of it was right. Problem was that I
didn't knew which 3% that was wrong... So it was not much use to me.
To sum up - yes that article is a describes a way to do BDD - but thats
only the first section. The resti is about tools. And they don't matter
as much. BDD is about talking to each other - which is best done without
tools.
Read more (and better probably) here: [http://dannorth.net/introducing-bdd/](http://dannorth.net/introducing-bdd/), [http://dannorth.net/whats-in-a-story/](http://dannorth.net/whats-in-a-story/) .
Thanks for giving me the opportunity to write this. I had to think hard,
as I knew that bright guys like you are going to read this. "
