Any hate/love relationship with BDD/TDD? cool stories?
Dan North wrote:I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved. I now had answers to some of those TDD questions. What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails, simply work through the process described above – either you introduced a bug, the behaviour moved, or the test is no longer relevant.
I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.
In short, the original definition of BDD was more or less "TDD with a different vocabulary". In the recent years, BDD has grown to mean all sorts of things beyond the original idea. For instance, some people use it as a synonym for acceptance test-driven development (ATDD).
With that said, I've only seen one actual (non-technical) customer create executable examples directly in a computer-understandable format. That was almost 10 years ago when we gave our client a spreadsheet with some examples and she would expand on those examples, adding corner cases etc. In every other organization where I've seen specification by example in practice, the tools have been so obviously limiting and cumbersome that the real collaboration has happened with good ol' pen and paper and the team has encoded the examples from those conversations into various digital formats afterwards.
Having those concrete examples is pure awesome! Whether they're encoded into an executable format and can be run with a single command is somewhat secondary to me. A very nice bonus, if you will, but certainly not the beef.