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
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]
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
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
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
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
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
ritasker
nijieinfra
ivanova1991
findyinc
sanfrecce_osaka
zerebom
philipschwarz
kazupon
techouse
pospome
ivargrimstad
miyuki2203
doggy
holman
pedronauck
destraynor
frogandcode
colly
lauravandoore
edds
myddelton
trallard
quramy
garrettdimon
jlugia