Why you should be doing BDD

Why you should be doing BDD

A brief introduction to Behavior Driven Development, accompanied with my story of how I applied it to a project.

Ad3967ce9151013b7a5d3908ed369ce0?s=128

Richard Tasker

October 18, 2014
Tweet

Transcript

  1. 1.
  2. 2.
  3. 5.

    Problems of TDD • Where to start • What to

    test and what not to test • How much to test in one go • What to call their tests • How to understand why a test fails
  4. 7.

    An Expressive Test Name Helps When a Test Fails •

    A bug has been introduced • Behaviour has moved • Behaviour has been Removed
  5. 12.
  6. 14.
  7. 17.

    User Stories and Acceptance Criteria As [a user] I want

    to [do something] So that I can [complete a task] In order to [complete a task] As [a user] I {must/should/could/wont} [do something]
  8. 18.

    MoSCoW Priorities • Must - Core requirements that must be

    included in the project • Should - High priority requirements, to be included in the project if possible • Could - Desirable requirements, not necessary to the project • Won’t - Requirements that will not be implemented in a given release, but may be considered in the future
  9. 19.

    Example User Stories In order to maintain an up to

    date Vehicle database As a Vehicle Administrator I must be able to create a new Vehicle In order to maintain an up to date Vehicle database As a Vehicle Administrator I must be able to edit an existing Vehicle In order to collate a list of Parts for a Vehicle As a Vehicle Administrator I must be able to apply a Part to a Vehicle
  10. 21.

    Example Scenarios In order to maintain an up to date

    Vehicle database As a Vehicle Administrator I must be able to create a new Vehicle Given I have no Vehicles When I create a Volkswagen Golf 2.0 Then I should have a Volkswagen Golf 2.0 Given I have a Volkswagen Golf 2.0 When I create a Volkswagen Golf 2.0 Then I should receive a No Duplicates error
  11. 22.

    Incorporating Acceptance Tests 1. Write a failing acceptance test 2.

    Write a unit test, which fails 3. Write a little bit of code 4. Rerun tests 5. Repeat steps 2 - 4 until all tests pass
  12. 23.
  13. 25.

    Why Should You Be Doing BDD • Great for teams

    new to TDD • Reduces communication barriers • Priorities requirements • Helps with naming objects • Everyone knows when a feature is done