So here's a summary of their thoughts:
- Most of the challenges are not particularly tool specific and often it is writing useful "acceptance tests" or "examples" in BDD parlance is where people get caught up.
- Tools are useful but shouldn't be an obstacle during the discussion and documenting of scenarios. Recommended tools included Cucumber and JBehave which have plain text features and scenarios. The separation of implementation details from the scenarios helps one focus on the scenarios and language at the right level i.e. at the business level. The discussion of examples with stakeholders, developers, QAs, BAs then proceeds more naturally.
- A recommended read is Specification by example book as it is brimming with examples of how people have applied the BDD techniques. It's not a book that will hand hold you through writing scenarios, but it will help you to understand what scenarios and features should be about.
- In a previous blog, I discounted Cucumber as being too Ruby centric. I now stand corrected. Cucumber isn't just for Rubyist. While the tool itself is written in Ruby, it has bindings to many popular languages on the JVM through Cuke4Duke including Java, Scala, Groovy and Clojure. This allows the automation of step definitions in the language of your choice and integrates reasonably well into build tools such as Ant and Maven. Aslak Hellesoy, the creator of Cucumber, is working on a pure Java version of Cucumber with intended tighter support with JUnit and other testing frameworks.
Division of labour
- Regarding the roles of team members in writing and automating specifications, it all depends on the technical skill levels of members of your team. Generally it is developers and QA writing scenarios, with input from product owner types.
- Ideally a developer or tester would be pairing with a stakeholder as they break down the key examples. Other examples can later be filled in as they are thought of and run by the interested stakeholder.
- Automation will initially require someone with strong coding skills whether that be a developer or a QA with good programming knowledge. Once the foundations are there it becomes easier for less programming oriented members to follow existing examples in the code base.
- It's important to treat the automation layer as a first class citizen in regard to refactoring and cleanliness.
What about unit tests?
Overlap with unit level tests is something to be wary of. It often means there are many high level scenarios and possibly every permutation does not need to be covered at the top level. A balance is usually required since functional/scenario level tests are generally slower to run and more expensive to maintain.
Links for further investigation
Below are some links that might on getting started with BDD on the JVM:
- http://cuke4ninja.com/
- http://www.rapaul.com/tag/cucumber/
- An informative talk on Cucumber on the JVM with Groovy.
- https://github.com/aslakhellesoy/cuke4duke/tree/master/examples (JVM language examples)
- http://specificationbyexample.com/ (the long term benefits of specification by example/BDD)
- Joseph Wilk from Songkick gave a very interesting talk on how they adopted BDD and Cucumber and talked about lessons learnt.
The aforementioned comments and guidance have been very helpful and informative. I'm sure it'll stand me in good stead when I get round to a BDD spike in the next few weeks.
