1. ATDD in practice
Andrei Marukovich
andrei.marukovich@lunarfrog.com
Twitter @amarukovich
:
Blog: lunarfrog.com/blog

2. Agenda
• What is Acceptance Test Driven
Development?
• ATDD in depth
• SpecFlow demo
2

3. Story of ProjectX
• Ingredients of success
• Dedicated team and comfortable schedule
• Continues integration server
• High Unit Tests coverage
• Regular architecture reviews
• Metrics analyzes
3

4. Project was rejected by the customer
“Actually, we asked for something different”
4

5. Reason of the failure
1. Initial
requirements
Sales
Customer
Department
3. Wrong
product
2. Adjusted
Development requirements
Team
Lack of communication
5

6. ATDD is about…
• Communication
• Collaboration
• Process improvements
• Better specifications
6

7. ATDD is not about frameworks
7

8. Definition
• TDD helps to develop product right
• ATDD helps to develop right product
• Other names:
• Behavior Driven Development
• Specification by example
• Executable specification
8

9. ATDD and TDD
Refactor Red
TDD
Specify Develop
Green
ATDD
Deliver
9

10. Specify
All stakeholders collaborate on specification
Domain Developers Testers Specification
Define Clarify Verify
Specification based on common
understanding
10

11. Workshop types
• Full team
• Mini-team
• 1 domain expert + 1 developer + 1 tester
• Pairing
• Useful for extending existing specifications
11

12. Specification
• Use domain language
• Testable
• Includes scenarios and examples
12

13. Specification example
Feature: New user registration
In order to be able to use site
As a new user
I want to be able to register an account
Scenario: Successful registration
Given I am on Registration page
When I entered unique name
And I entered valid password
Then a new account is created
13

14. Executable specification benefits
• Better definition of scope and “done”
• More scenarios identified upfront
• Preventing defects is cheaper than fixing
them
• Prevents system regression
14

15. What to specify
• User Interface?
• Business logic?
• Data access layer?
• Algorithms?
Everything, if it make sense for customer
15

16. Consider maintenance cost
Business logic and DAL UI and Algorithms
16

17. How to specify
• Define system behavior, not steps
• Simplifies long term maintenance
• Captures domain knowledge
• Do not rely on implementation details
• Test should be self-describing
• Define allowed and disallowed scenarios
• Provide right and failing examples
• Use iterative approach
• Start with defining of the happy path
• Use domain language
17

18. What’s next?
It’s time to automate your specifications
18

19. Frameworks - FIT
19

20. Fixture implementation
Production
FIT Fixture
Code
20

21. FIT Action fixture
21

22. Given-When-Then frameworks
• Cucumber
• Cuke4Nuke
• SpecFlow
22

23. Gherkin style specification
Feature: New user registration
In order to be able to use site
As a new user
I want to be able to register an account
Scenario: Successful registration
Given I am on Registration page
When I entered unique name
And I entered valid password
Then a new account is created
23

24. Demo
SpecFlow demo
24

25. Test maintenance
• Automation code is code – follow all good
habits
• Document building blocks
• Split the test – fast, slow, stable
• ATDD can be used for integration but keep
integration and functional tests separately
25

26. Way for a better specifications
• Collaborative approach
• Specify behavior, not implementation
• Testable requirements
• Automate specification tests
• Control specification maintainability
26

27. Thank you!
lunarfrog.com/blog
@amarukovich
27