extreme readable acceptance testing
Post on 12-Apr-2017
355 Views
Preview:
TRANSCRIPT
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
top related