Executable Specifications in Action
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Executable Specifications in Action

on

  • 915 views

Executable specifications in action: building in-memory mobile bank

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

Statistics

Views

Total Views
915
Views on SlideShare
915
Embed Views
0

Actions

Likes
1
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Executable Specifications in Action Presentation Transcript

  • 1. Executable specifications in action Building mobile bank Vagif Abilov, Miles AS
  • 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. I showed this screenshot in 2009…
  • 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. 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. Combining BDD and TDD Failing step Refactor Passing step
  • 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. 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. Язык ГеркинФункционал: Продажа кофе Чтобы заработать Заказчики должен иметь возможность купить в любой момент кофе Сценарий: Купить последнюю чашку кофе Пусть в кофейном автомате есть кофе на 1 чашку И я опущу 1 рубль Когда я нажму кнопку выдачи кофе Тогда я должен получить чашку кофе
  • 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. 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. 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. 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. Practice Building executable specifications and implementing features of a mobile bank Source code for this workshop: https://github.com/object/InMemoryBank
  • 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. Scenarios Send money between two registered users Send money from unregistered user Send money to unregistered user Insufficient balance
  • 17. Sensing mobile bank SMS Push In We don’t want to know SMS Inspect Out
  • 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. 0. The scope is defined A B C D
  • 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. 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. 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. 1. Feature completion report
  • 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. 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. 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. 2. Feature completion report
  • 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. 3. Feature completion report
  • 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. 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. 4. Feature completion report
  • 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. 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. 5. Feature completion report
  • 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. 6. Feature completion report
  • 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. 7. Feature completion report
  • 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. 8. Feature completion report
  • 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. 9. Feature completion report
  • 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. 10. Feature completion report
  • 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. 11. Feature completion report
  • 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. 12. Feature completion report
  • 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. 13. Feature completion report
  • 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. 14. Feature completion report
  • 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. 15. Feature completion report
  • 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. Executable specifications in action Thank you!