Testing
Everyone should be doing TDD already. There’s really no excuse for not doing it, however the big dilemma is the amount of tests, how long they run and what to test and what not to test. There are even religious arguments about the different types of tests, e.g. unit tests, integration tests, contract tests, acceptance tests etc. Where does one start, where does the other end?
The bigger question here is, does it matter? That’s up to you to decide.
BDD
As if there wouldn’t be enough discussions and arguments we also have BDD (follow the link if you want to know more!) which gains momentum. It’s promise and expectations are that it will focus on what really matters. No more unnecessary tests, no more missing test cases, everything as defined by the BA, product owner or even the customer!
But now the question is, how well does the customer or the product owner know what they want (I’m excluding the BA here!)? Or rather what they need? We’ve all been there, requirements usually change because they’re often not thought through in all detail, or aren’t doable in a timely manner.
My view
That’s what stops me from implementing BDD, it complicates TDD with it’s own DSL which is supposed to simplify things but makes it more complicated for developers. But in the end the developers will still have to own the test cases or user stories as the customers and/or product owners won’t write all or maintain them. There are certainly exceptions where BDD can add value but I see it more as just another thing that makes a developers life harder instead of easier.
That doesn’t mean though that I’m not tempted in giving it a go given the right environment. But you will require very technical and detailed BAs to be able to get BDD working perfectly.
BroddlIT 