The Start of BDD
It all started – or so I’ve read – with a guy named Dan North:
I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.
The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.
I felt this exact way when learning up on TDD:
- where do I start?
- what do I do next?
- how do I know when I get there?
Things like that. I still don’t know those answers, but I feel like BDD has helped me see some very interesting ways to address these issues. Moreover, it will help me get along with my PM better – maybe 
.
The Usual Caveats
No – I’m not an expert. Please don’t take any of what you’re about to say as guidance. Do take it as queue to find out more. Do ask a lot of questions and Do challenge yourself to see what some people love to use.
