Executable Specifications in Action
-
Upload
vagif-abilov -
Category
Technology
-
view
749 -
download
0
description
Transcript of Executable Specifications in Action
Executable specifications in action Building mobile bank
Vagif Abilov, Miles AS
About myself
Mail: [email protected] 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!