Executable Specifications in Action

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://bloggingabout.net/blogs/vagif/default.aspx

Articles: http://www.codeproject.com

I showed this screenshot in 2009…

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 bloghttp://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

BDD cycle (from RSpec book)1. Focus on one scenario2. Write failing step definition

drop down to component code3. Write failing example4. Get the example to pass5. Refactorrepeat 3-5 until step is passing

6. Refactorrepeat 2-7 until scenario is passingrepeat 1-7 when scenario is passing

Combining BDD and TDD

Failing step

Passing stepRefactor

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.

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

Язык ГеркинФункционал: Продажа кофе Чтобы заработать Заказчики должен иметь возможность купить в любой момент кофе

Сценарий: Купить последнюю чашку кофе Пусть в кофейном автомате есть кофе на 1 чашку И я опущу 1 рубль Когда я нажму кнопку выдачи кофе Тогда я должен получить чашку кофе

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>

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

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»

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

Practice

Building executable specifications and implementing features of a mobile bank

Source code for this workshop:https://github.com/object/InMemoryBank

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

Scenarios

Send money between two registered users Send money from unregistered user Send money to unregistered user Insufficient balance

We don’t want to know

SMSOut

SMSIn

Sensing mobile bank

Push

Inspect

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”)

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 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

1. Scenario steps are defined

A

B

C

D

a b

c d

dc d

b

f b

c d

f g

b c

a

Generating feature completion report

"%ProgramFiles(x86)%\NUnit 2.5.10\bin\net-2.0\nunit-console.exe" %1

"%ProgramFiles(x86)%\TechTalk\SpecFlow\SpecFlow.exe" nunitexecutionreport %2 /xmlTestResult:%3 /out:TestResult.html

1. Feature completion report

2. Choose first scenario to implement

Send money between two registered users Send money from unregistered user Send money to unregistered user Insufficient balance

2. Start implementing steps

(a) Given user with phone number 92748326 is not registered(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 need to register. Command is cancelled. |(d) And no SMS should be sent to 95473893

2. Failed step definition that requires jumping into an inner circle

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c

a

2. Feature completion report

3. Write first failed implementation test

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

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 on making failing feature pass – and

nothing more!

4. First passed implementation test

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

4. Feature completion report

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

5. Implementation refactoring

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

5. Feature completion report

6. Adding implementation tests until the failing step passes

A

B

C

D

a b

c d

ed

f

d

f g

ab

c1

2

cb

b

c

b c

a

6. Feature completion report

7. At last first passed scenario

A

B

C

D

a b

c d

ed

f

d

f g

ab

c1

2d

cb

b

c

b c

a

7. Feature completion report

8. Moving to the next scenario

A

B

C

D

a b

c d

ec

b

f

f g

a

ab

c1

2d

ed

d

b

c

b c

8. Feature completion report

9. Adding failed implementation test

A

B

C

D

a b

c d

ec

b

f

f g

a

ab

c1

2d

3 ed

d

b

c

b c

9. Feature completion report

10. Making second scenario pass

A

B

C

D

a b

c d

ec d

b

f

f g

a

ab

c1

2d

3

4

5

e

d

b

c

b c

10. Feature completion report

11. More implemented steps,more failed scenarios

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

2d

3

4

5

e

f

g

11. Feature completion report

12. Adding failed implementation test

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

2d

3

4

5

e

f

g

6

12. Feature completion report

13. Making third scenario pass

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

2d

3

4

5

e

f

g

67

8

13. Feature completion report

14. More failed implementation tests

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

2d

3

4

5

e

f

g

67

89

14. Feature completion report

15. The feature is complete!

A

B

C

D

a b

c d

ec d

b

f b

c d

f g

b c

a

ab

c1

2d

3

4

5

e

f

g

67

890

15. Feature completion report

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

Executable specifications in action

Thank you!