I'm interested in hearing John's suggestions, but if you're a developer, I'd suggest doing it the same way folks introduced TDD; start doing it yourself, then - if it works for you - show your team mates.
It's pretty easy to get started with Spock, and I know John covers it in his book.
Give it a try then share what you learned.
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Adopting BDD at the code level, particularly in your own code, is certainly a quick win. Even just changing the way you name methods in JUnit tests (e.g. don't use the word 'test' - use a sentence containing the word 'should') is a start. The benefits are easy to see, and the organizational changes required are minimal. Also try to adopt a top-down approach to discovering components and services, mocking them out while you focus on the class you are currently working on - this is the "London-style" of TDD, and is very effective when building larger systems.
Of course if you limit BDD to the coding level, you won't be getting all of the benefits, and you will probably want to expand BDD to automated acceptance criteria. A lot of the benefits of BDD practices happen when they encourage and leverage better communication and feedback within the team and between the team and stakeholders. This is where you can be more confident not just that your code is not buggy, but that it maps to what will deliver real value to the stakeholders.
You can start with automated functional tests, for example using something like JBehave/Thucydides, or even just JUnit/Thucydides (assuming a JVM environment), to demonstrate the usefulness of living documentation. Moving to proper BDD at the requirements level is like moving to Scrum or another agile process - it involves organizational change within the team, and regarding how the team works with stakeholders. Over-the-wall QA won't work well with BDD. Detailed upfront specs "signed off" by the business won't work either. BDD moves beyond both of these approaches. It is more natural if the team is already practicing Scrum (or another Agile process), as Scrum absolutely depends on practices such as test automation and well-defined acceptance criteria to work. If you are not doing Agile at all, consider adopting a more Agile/Lean process first, as high-level BDD encourages/is built on close collaboration and communication between BAs, devs, testers and stakeholders (or the Product Owner in a Scrum project).
Joined: Oct 01, 2001
John Smart wrote:Scrum absolutely depends on practices such as test automation and well-defined acceptance criteria to work.
Can you give me a reference for your statement about Scrum depending on test automation? We're moving to Scrum and I'd love to have something I can point to like that. I've been recommending more TDD and BDD, but many of the dev teams are reluctant because of the perceived overhead in writing the tests. If I can point to something showing that Scrum expects devs to write automated tests, then it will be easier to make that part of the time estimates for each sprint.