wood burning stoves 2.0*
The moose likes Design and the fly likes What's the best way to introduce BDD in our companies? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Design
Bookmark "What Watch "What New topic
Author

What's the best way to introduce BDD in our companies?

Rogerio Kioshi
Ranch Hand

Joined: Apr 12, 2005
Posts: 689
For those who don't apply any kind of tests in their companies...


SCEA 5 (part 1), SCBCD, SCWCD, SCJP, CLP, CLS
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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.

Burk


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
John Smart
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 33
    
    5
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).
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
John Smart wrote:Scrum absolutely depends on practices such as test automation and well-defined acceptance criteria to work.

John,
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.

Thanks,
Burk
John Smart
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 33
    
    5
Strictly speaking, Scrum doesn't mandate a great deal of things regarding technical practices - it focuses pretty much entirely on project organization matters. But Scrum experts will confirm that you can't do sustainable Scrum without good technical practices. Consider:
- http://martinfowler.com/bliki/FlaccidScrum.html
- http://blog.mattwynne.net/2013/08/12/half-arsed-agile/
- http://www.scrumalliance.org/community/articles/2009/november/the-top-six-technical-practices-every-product-owne
- "Improving Technical Practices Is Not Optional" - Mike Cohn, "Succeeding With Agile", page 171 (the book as a whole is worth reading as it deals with a lot of objections of this sort)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What's the best way to introduce BDD in our companies?
 
Similar Threads
WA #1.....word association
Associate Consultant
CSC (Computer Science Corporation)
Schneider Electric
What do you notice more