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
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 рубль
Когда я нажму кнопку выдачи кофе
Тогда я должен получить чашку кофе
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
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”)
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
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
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
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
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