February 9, 2007

...Learn TDD with Codemanship

Behaviour-driven Development - Wheel-driven Reinvention?

Cynics would say that the definition of a politician is a person who pushes to the front of a marching crowd and shouts "follow me". I kind of get that sense with Behaviour-driven Development. It all sounds strikingly familiar: you specify system behaviour in specific test scenarios using a formal (ideally executable) specification language, expressing that behaviour in terms of a well-defined conceptual model of the problem domain that all key project stakeholders understand.

We used to call that "formal specification", chaps, and some of us have been doing it for years. No doubt the BDD-ers will argue: "but we can execute our specifications as automated tests". Yep. Did that back in the 90's. "Oh, but we don't specify the entire system before we write the code. We let our specifications - and our implementations - evolve through rapid cycles of delivery and feedback." Yep. Been doing that the whole time I've been doing TDD, which is about 6 years, now.

Methods like Syntropy, Catalysis and Fusion were all behaviour-driven, iterative and - compared to the likes of RUP and SSADM - lightweight. When TDD started to become popular in 2000, I immediately started to apply the principles I'd learned from these methods to the TDD process. I always go to some pains to maintain a visible domain model (usually on a whiteboard where everyone can see it), and I always try to write tests that read like specifications and are couched in terms of that domain model.

What annoys me slightly is that a few years ago I would get into quite heated debates with various well-known Agilistas who would insist that formal specification was a waste of time. The very same people are now singing the praises of BDD. If I'd known that all I had to do was come up with a new name for it...
Posted 13 years, 10 months ago on February 9, 2007