Executable specifications in action: building mobile bank In this workshop we exercise a combination of BDD and TDD methods by implementing a small mobile bank solution. We start from user stories and scenarios turning them into a set of executable specifications written in Gherkin language. Then we proceed with implementation of scenario steps followed by writing production code in a test-driven manner. By the end of the workshop we have an in-memory bank communicating with its customers using simulated SMS messages.

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
development
Neel Lakshminarayan’s blog
http://neelnarayan.blogspot.com/2010/07/bdd-is-more-
than-tdd-done-right.html

5. BDD cycle (from RSpec book)
1. Focus on one scenario
2. 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 passing
6. Refactor
repeat 2-7 until scenario is passing
repeat 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 in
English (or the language of your choice). Cucumber
will parse the feature and generate test templates
(a.k.a. step definitions) that the developer will be
completing.
Cucumber language grammar is called Gherkin.

8. Gherkin language
Feature: 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 in
Gherkin
 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 to
Visual 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 not
registered
(b) When user sends SMS
Phone number | Message |
| 92748326 | PAY 10 95473893 |
(c) Then following SMS should be sent
| Phone number | Message |
| 92748326 | In order to use InMemory Bank you need
to register. Command is cancelled. |
(d) And no SMS should be sent to 95473893

26. 2. Failed step definition that requires
jumping 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 the
failing 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!