Executable specifications in action            Building mobile bank                   Vagif Abilov, Miles AS
About myself   Mail: vagif.abilov@gmail.com   Twitter: @ooobject   GitHub: object   BitBucket: object   Blog:    http...
I showed this screenshot in 2009…
BDD is more than «TDD done right»   Developing features that truly add business value   Preventing defects rather than f...
BDD cycle (from RSpec book)1. Focus on one scenario2. Write failing step definition      drop down to component code      ...
Combining BDD and TDD                  Failing step       Refactor                  Passing step
Cucumber and Gherkin   Cucumber    (https://github.com/aslakhellesoy/cucumber)   Gherkin (https://github.com/aslakhelles...
Gherkin languageFeature: Serve coffee In order to earn money Customers should be able to buy coffee at all times Scenario:...
Язык ГеркинФункционал: Продажа кофе Чтобы заработать Заказчики должен иметь возможность купить в любой момент кофе Сценари...
Language definition<Language englishName="Norwegian" defaultSpecificCulture="nb-NO"cultureInfo="no" code="no">         <Fe...
Advantages of writing specifications inGherkin   Understandable across the team   Focused on features   Not coupled to ...
Some books and articles before we move to.NET and Visual Studio   Dan North. «Introducing BDD»   Gojko Adzic. «Bridging ...
So how we bring executable specifications toVisual Studio ecosystem?   Cuke4Nuke (discontinued last week in favour of    ...
Practice    Building executable specifications and   implementing features of a mobile bank        Source code for this wo...
Feature: SMS payments   In order to instantly make money transfers   As a mobile bank user   I want to use SMS to send ...
Scenarios   Send money between two registered users   Send money from unregistered user   Send money to unregistered us...
Sensing mobile bank               SMS      Push                In                     We don’t want to know               ...
Common for all scenarios   Set up the execution context by ensuring certain    bank users are registered or unregistered ...
0. The scope is defined   A   B   C   D
1. Defining scenario steps   Define Given/When/Then steps for each scenario   Try to make steps reusable so once they ar...
1. Scenario steps are defined       a b   A       c d       d a b   B   c d       f   b   C       c d       f   g   D   b c
Generating feature completion report   "%ProgramFiles(x86)%NUnit 2.5.10binnet-    2.0nunit-console.exe" %1   "%ProgramFi...
1. Feature completion report
2. Choose first scenario to implement   Send money between two registered users   Send money from unregistered user   S...
2. Start implementing steps(a) Given user with phone number 92748326 is notregistered(b) When user sends SMSPhone number |...
2. Failed step definition that requiresjumping into an inner circle        a b                        a    A              ...
2. Feature completion report
3. Write first failed implementation test       a b                      a   A                                b       c d ...
3. Feature completion report
4. Make failed test pass   Within the inner circle we apply TDD as we are used    to   Red – green – refactor   Focus o...
4. First passed implementation test       a b                    a   A                              b       c d           ...
4. Feature completion report
5. Implementation refactoring   We started with all-in-one MessageProcessor   It gave us a quick kick-start and let us b...
5. Implementation refactoring       a b                      a   A                                b       c d             ...
5. Feature completion report
6. Adding implementation tests until thefailing step passes       a b                          a   A                      ...
6. Feature completion report
7. At last first passed scenario       a b                         a   A                                   b       c d    ...
7. Feature completion report
8. Moving to the next scenario       a b                        a   A                                  b       c d        ...
8. Feature completion report
9. Adding failed implementation test       a b                           a   A                                     b      ...
9. Feature completion report
10. Making second scenario pass       a b                              a   A                                        b     ...
10. Feature completion report
11. More implemented steps,more failed scenarios       a b                                a   A                           ...
11. Feature completion report
12. Adding failed implementation test       a b                               a   A                                       ...
12. Feature completion report
13. Making third scenario pass       a b                                a   A                                          b  ...
13. Feature completion report
14. More failed implementation tests       a b                                  a   A                                     ...
14. Feature completion report
15. The feature is complete!       a b                                    a   A                                           ...
15. Feature completion report
Final thoughts   Writing specifications in executable format make    them live   Executable specification is a living do...
Executable specifications in action              Thank you!
Upcoming SlideShare
Loading in …5
×

Executable Specifications in Action

919 views
848 views

Published on

Executable specifications in action: building in-memory mobile bank
Slides from the presentation at NNUG Oslo. October 25, 2011.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
919
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Executable Specifications in Action

  1. 1. Executable specifications in action Building mobile bank Vagif Abilov, Miles AS
  2. 2. About myself Mail: vagif.abilov@gmail.com Twitter: @ooobject GitHub: object BitBucket: object Blog: http://bloggingabout.net/blogs/vagif/default.aspx Articles: http://www.codeproject.com
  3. 3. I showed this screenshot in 2009…
  4. 4. BDD is more than «TDD done right» Developing features that truly add business value Preventing defects rather than finding defects Bring QA involvement to the forefront Define executable, verifiable and unambiguous requirements Provide a better definition of “DONE” for agile developmentNeel Lakshminarayan’s bloghttp://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html
  5. 5. BDD cycle (from RSpec book)1. Focus on one scenario2. Write failing step definition drop down to component code 3. Write failing example 4. Get the example to pass 5. Refactor repeat 3-5 until step is passing6. Refactorrepeat 2-7 until scenario is passingrepeat 1-7 when scenario is passing
  6. 6. Combining BDD and TDD Failing step Refactor Passing step
  7. 7. Cucumber and Gherkin Cucumber (https://github.com/aslakhellesoy/cucumber) Gherkin (https://github.com/aslakhellesoy/gherkin)Cucumber is a BDD testing framework written in Ruby.When using Cucumber you describe your features inEnglish (or the language of your choice). Cucumberwill parse the feature and generate test templates(a.k.a. step definitions) that the developer will becompleting.Cucumber language grammar is called Gherkin.
  8. 8. Gherkin languageFeature: Serve coffee In order to earn money Customers should be able to buy coffee at all times Scenario: Buy last coffee Given there are 1 coffees left in the machine And I have deposited 1$ When I press the coffee button Then I should be served a coffee
  9. 9. Язык ГеркинФункционал: Продажа кофе Чтобы заработать Заказчики должен иметь возможность купить в любой момент кофе Сценарий: Купить последнюю чашку кофе Пусть в кофейном автомате есть кофе на 1 чашку И я опущу 1 рубль Когда я нажму кнопку выдачи кофе Тогда я должен получить чашку кофе
  10. 10. Language definition<Language englishName="Norwegian" defaultSpecificCulture="nb-NO"cultureInfo="no" code="no"> <Feature>Egenskap</Feature> <Background>Bakgrunn</Background> <Scenario>Scenario</Scenario> <ScenarioOutline>Scenariomal</ScenarioOutline> <ScenarioOutline>Abstrakt Scenario</ScenarioOutline> <Examples>Eksempler</Examples> <Given>Gitt</Given> <When>Når</When> <Then>Så</Then> <And>Og</And> <But>Men</But></Language>
  11. 11. Advantages of writing specifications inGherkin Understandable across the team Focused on features Not coupled to framework API (less brittle) Not dependent on programming languages or platforms Can be maintained in different human languages Enables feature progress tracking, not just API implementation failures
  12. 12. Some books and articles before we move to.NET and Visual Studio Dan North. «Introducing BDD» Gojko Adzic. «Bridging the Communication Gap» Gojko Adzic. «Specification by Example» David de Florinier et al. «The Secret Ninja Cucumber Scrolls» a.k.a. Cuke4Ninja. David Chelimsky et al. «The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends» Steve Freeman, Nat Pryce. «Growing Object- Oriented Software, Guided by Tests»
  13. 13. So how we bring executable specifications toVisual Studio ecosystem? Cuke4Nuke (discontinued last week in favour of SpecFlow) • https://github.com/richardlawrence/Cuke4Nuke • Requires Cucumber • Requires Ruby SpecFlow • https://github.com/techtalk/SpecFlow • Implements Gherkin but does not require Cucumber • Installed as an add-in to Visual Studio 2008/2010 • Supports NUnit, MSTest, xUnit.Net, MbUnit • Intellisense support in Gherkin
  14. 14. Practice Building executable specifications and implementing features of a mobile bank Source code for this workshop: https://github.com/object/InMemoryBank
  15. 15. Feature: SMS payments In order to instantly make money transfers As a mobile bank user I want to use SMS to send money to other users
  16. 16. Scenarios Send money between two registered users Send money from unregistered user Send money to unregistered user Insufficient balance
  17. 17. Sensing mobile bank SMS Push In We don’t want to know SMS Inspect Out
  18. 18. Common for all scenarios Set up the execution context by ensuring certain bank users are registered or unregistered (“Given”) Perform a command by sending an SMS message to the mobile bank (“When”) Validate that the mobile bank responds with the expected SMS messages (“Then”)
  19. 19. 0. The scope is defined A B C D
  20. 20. 1. Defining scenario steps Define Given/When/Then steps for each scenario Try to make steps reusable so once they are implemented they can be applied to different scenarios Organize steps by domain concept Feature-coupled steps are considered anti-patterns Conjunction steps are considered anti-patterns
  21. 21. 1. Scenario steps are defined a b A c d d a b B c d f b C c d f g D b c
  22. 22. Generating feature completion report "%ProgramFiles(x86)%NUnit 2.5.10binnet- 2.0nunit-console.exe" %1 "%ProgramFiles(x86)%TechTalkSpecFlowSpecFlo w.exe" nunitexecutionreport %2 /xmlTestResult:%3 /out:TestResult.html
  23. 23. 1. Feature completion report
  24. 24. 2. Choose first scenario to implement Send money between two registered users Send money from unregistered user Send money to unregistered user Insufficient balance
  25. 25. 2. Start implementing steps(a) Given user with phone number 92748326 is notregistered(b) When user sends SMSPhone number | Message || 92748326 | PAY 10 95473893 |(c) Then following SMS should be sent| Phone number | Message || 92748326 | In order to use InMemory Bank you needto register. Command is cancelled. |(d) And no SMS should be sent to 95473893
  26. 26. 2. Failed step definition that requiresjumping into an inner circle a b a A b c d c e a b B c d f b C c d f g D b c
  27. 27. 2. Feature completion report
  28. 28. 3. Write first failed implementation test a b a A b c d 1 c e a b B c d f b C c d f g D b c
  29. 29. 3. Feature completion report
  30. 30. 4. Make failed test pass Within the inner circle we apply TDD as we are used to Red – green – refactor Focus on making failing feature pass – and nothing more!
  31. 31. 4. First passed implementation test a b a A b c d 1 c e a b B c d f b C c d f g D b c
  32. 32. 4. Feature completion report
  33. 33. 5. Implementation refactoring We started with all-in-one MessageProcessor It gave us a quick kick-start and let us better understand how we want to partition our system Now we can recall Single Responsibility Principle and split it into more granular components  SmsGateway  SmsParser  PaymentCommand  CommandProcessor
  34. 34. 5. Implementation refactoring a b a A b c d 1 c e a b B c d f b C c d f g D b c
  35. 35. 5. Feature completion report
  36. 36. 6. Adding implementation tests until thefailing step passes a b a A b c d 1 c 2 e a b B c d f b C c d f g D b c
  37. 37. 6. Feature completion report
  38. 38. 7. At last first passed scenario a b a A b c d 1 c 2 e a b d B c d f b C c d f g D b c
  39. 39. 7. Feature completion report
  40. 40. 8. Moving to the next scenario a b a A b c d 1 c 2 e a b d B c d e f b C c d f g D b c
  41. 41. 8. Feature completion report
  42. 42. 9. Adding failed implementation test a b a A b c d 1 c 2 e a b d B c d 3 e f b C c d f g D b c
  43. 43. 9. Feature completion report
  44. 44. 10. Making second scenario pass a b a A b c d 1 c 2 e a b d B c d 3 e f b 4 C c d 5 f g D b c
  45. 45. 10. Feature completion report
  46. 46. 11. More implemented steps,more failed scenarios a b a A b c d 1 c 2 e a b d B c d 3 e f f b 4 C g c d 5 f g D b c
  47. 47. 11. Feature completion report
  48. 48. 12. Adding failed implementation test a b a A b c d 1 c 2 e a b d B c d 3 e f f b 4 C g c d 5 f g 6 D b c
  49. 49. 12. Feature completion report
  50. 50. 13. Making third scenario pass a b a A b c d 1 c 2 e a b d B c d 3 e f f b 4 C g c d 5 f g 6 D b c 7 8
  51. 51. 13. Feature completion report
  52. 52. 14. More failed implementation tests a b a A b c d 1 c 2 e a b d B c d 3 e f f b 4 C g c d 5 f g 6 D b c 7 9 8
  53. 53. 14. Feature completion report
  54. 54. 15. The feature is complete! a b a A b c d 1 c 2 e a b d B c d 3 e f f b 4 C g c d 5 f g 6 D 0 b c 9 7 8
  55. 55. 15. Feature completion report
  56. 56. Final thoughts Writing specifications in executable format make them live Executable specification is a living documentation Specifications are the result of a communication that includes various project members Easy to track progress – some teams say they even don’t need burndown charts anymore Write code outside in: start from features and scenarios Unit and integration tests are still there
  57. 57. Executable specifications in action Thank you!

×