atdd in practice

ATDD in practice

Andrei Marukovichandrei.marukovich@lunarfrog.com

Twitter:

@amarukovich

Blog: lunarfrog.com/blog

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