Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Behavior-Driven Design: One Team's Exploration


Published on

Looking into a team’s experience with adopting Behavior-Driven Development (BDD) and at answering these questions:
- Why did we try it?
- What tools and processes did we adopt?
- How did it go?

Published in: Software
  • Be the first to comment

  • Be the first to like this

Behavior-Driven Design: One Team's Exploration

  1. 1. Behavior-Driven Development One Team’s Exploration
  2. 2. Behavior-Driven Development Or… ● BDD ● Acceptance Test-Driven Development ● Specification by Example ● ...
  3. 3. What is BDD? ● Focuses on specifying behavior instead of writing tests ● Defines a language for writing behaviors that can be executed o Gherkin - Given-When-Then statements
  4. 4. Why use BDD? ● functional, end-to-end testing ● communication o with product owner o with team members ● documentation ● building the right software
  5. 5. What’s wrong with TDD? ● Nothing ● Reading unit-tests harder for the business
  6. 6. What tools & processes did we use? We were building a REST service with Java, so…cucumber-jvm with groovy. ● simplified step-definition (vs Java) Given(~'^an order with all details$') {-> @Given("^a vehicle exists$") public void a_vehicle_exists() throws Throwable {
  7. 7. What tools & processes did we use? ● groovy - cucumber-spring integration o wasn’t strong, but can be worked around ● Could’ve used unit testing directly Scenario: place a valid order Given an order with all details When an order is placed Then a "CREATED" response is returned And the location of the new order is returned And a confirmation number is returned And the status is "ACTIVE" def “place a valid order”() { given: “an order with all details” when: “an order is placed” then: “a CREATED response is returned” and: “the location of the new order is returned” and: “a confirmation number is returned” and: “the status is ACTIVE” }
  8. 8. How did it go?
  9. 9. Better Team Communication
  10. 10. Less Assumptions Clarified assumptions with the Given clauses
  11. 11. Reviews and Unit Testing Code review focus ● Read tests first Unit test changes ● Used the Spock given-when-then structure, often with comments, to explain the test similar to Cucumber.
  12. 12. Product Owner Involvement Product Owner never ended up looking at the tests
  13. 13. Story Breakdown Difficulty with scrum story breakdown and swarming ● Starting with Cucumber feature left us feeling constrained with how the next steps would happen. ● How to get more than two people on it and still feel effective?
  14. 14. Others More time consuming Not everyone likes it
  15. 15. What would I do differently? ● Continue working on involving product owner ● Create feature statements as part of story creation ● Demonstrate progress through test report
  16. 16. Summary ● BDD was a good thing ● I think we should continue the practice o though stronger business involvement is needed for it to be truly effective
  17. 17. Questions