atdd in practice
DESCRIPTION
TRANSCRIPT
2
Agenda
• What is Acceptance Test Driven Development?
• ATDD in depth
• SpecFlow demo
3
Story of ProjectX
• Ingredients of success• Dedicated team and comfortable
schedule• Continues integration server• High Unit Tests coverage• Regular architecture reviews• Metrics analyzes
4
Project was rejected by the customer
“Actually, we asked for something different”
5
Reason of the failure
Sales Department
Development Team
Customer
1. Initial requirements
Lack of communication
2. Adjusted requirements
3. Wrong product
6
ATDD is about…
• Communication
• Collaboration
• Process improvements
• Better specifications
7
ATDD is not about frameworks
8
Definition
• TDD helps to develop product right
• ATDD helps to develop right product
• Other names:• Behavior Driven Development• Specification by example• Executable specification
9
ATDD and TDD
Develop
Deliver
Specify
Red
Green
Refactor
TDD
ATDD
10
Specify
All stakeholders collaborate on specification
Domain Developers Testers
Define Clarify Verify
Specification
Specification based on common understanding
11
Workshop types
• Full team
• Mini-team• 1 domain expert + 1 developer + 1
tester
• Pairing• Useful for extending existing
specifications
12
Specification
• Use domain language
• Testable
• Includes scenarios and examples
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
14
Executable specification benefits
• Better definition of scope and “done”
• More scenarios identified upfront
• Preventing defects is cheaper than fixing them
• Prevents system regression
15
What to specify
• User Interface?
• Business logic?
• Data access layer?
• Algorithms?
Everything, if it make sense for customer
16
Consider maintenance cost
UI and AlgorithmsBusiness logic and DAL
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
18
What’s next?
It’s time to automate your specifications
19
Frameworks - FIT
20
Fixture implementation
FIT Fixture Production Code
21
FIT Action fixture
22
Given-When-Then frameworks• Cucumber
• Cuke4Nuke
• SpecFlow
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
24
Demo
SpecFlow demo
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
26
Way for a better specifications• Collaborative approach
• Specify behavior, not implementation
• Testable requirements
• Automate specification tests
• Control specification maintainability
Thank you!
27
lunarfrog.com/blog
@amarukovich