• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 701
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For those who don't apply any kind of tests in their companies...
 
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Author
Posts: 43
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 43
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic