extreme readable acceptance testing

Extreme

Given

D

T

B

Developer

Tester

Business Analyst

Product OwnerP

DD

D T

B DD

D T

BD

DD

D T

BD

PT BD

Cross-functional-flat teams

Story driven iterations

Backlog Ready to Dev Ready to Test Ready to Close Release

Story driven iterations

Backlog Ready to Dev Ready to Test Ready to Close

BT

D

Release

ACs

3 Amigos

Story driven iterations

Backlog Ready to Dev Ready to Test Ready to Close Release

D

ATDD/TDD

ATs

Story driven iterations

Backlog Ready to Dev Ready to Test Ready to Close Release

T

ATs

ACs

vs

Story driven iterations

Backlog Ready to Dev Ready to Test Ready to Close Release

BT

D

Sign-off

ATs

ACs

+

● Define/prove system behaviour

● Sync and related to code

● Collaborative ownership

● Communication

When x000 features

And spec is not code

TXT

HTML

wiki

gherkin

code code

Specification Fixture System under test

Then

● Effort >> readable specification

● Hard to refactor

● Hard to maintain Legacy

Acceptance tests

TXT

HTML

wiki

gherkin

code code

Specification Specification + Fixture

System under test

YatSpecYet Another Test Specification Library

github.com/bodar/yatspec

Test file name

Test name

Test code

<code>

github.com/alexfdz/rest-bdd

● spec AND code readability

● unit tests and production code

● easy to maintain

Q&A

Alex Fernandez

@_alexfdz

alexfdz

afernandeznogueria