Test Driven
Lasse Koskela
Chapter 9: Acceptance TDD Explained
Paul Ammann
http://cs.gmu.edu/~pammann/
Overview
•
•
•
•
•
•
•
Introduction to User Stories
Acceptance Tests
Understanding the Process
Acceptance TDD as a Team Activity
Benefits of Acceptance TDD
What Are We Testing, Exactly?
Brief Overview of Available Tools
In the Spacecraft business no design can survive the
review process without first answering the question – how
are we going to test this thing?
7/1/2016
2
Introduction To User Stories
• Format of a Story
– As a (role) I want (functionality) so that (benefit).
– May Record These On Index Cards
• CCC: Card, Conversation, Confirmation
• Power of Storytelling
– User View of What Is Needed, But No “How” Information
• Examples of User Stories
– “Support technician sees customer’s history onscreen at the start of a call”
– “The system prevents user from running multiple instances of the
application simultaneously”
Storytelling Reveals Meaning Without Committing the
Error of Defining It.
7/1/2016
3
Acceptance Tests
• Example Tests For a Story
• Properties of Acceptance Tests
–
–
–
–
–
Owned By Customer
Written Together With Customer, Developer, and Tester
Focus on the What, not the How
Expressed in the Language of the Problem Domain
Concise, Precise, and Unambiguous
• Implementing Acceptance Tests
– This Means Automating Them
– Use Whatever Framework is Most Convenient
These Are Basically Use-Cases
7/1/2016
4
Acceptance Tests(2): Example Stories
• Simulate a call with Fred’s account number and verify
that Fred’s info can be read from the screen.
• Verify that the system displays a valid error message for
a non-existing account number.
• Omit the account number in the incoming call
completely and verify that the system displays the text
“no account number provided” on the screen.
Three Acceptance-TDD Stories
7/1/2016
5
Acceptance Tests(3): Too Much Information
• Go to the “new transaction” screen, fill in the required
details, and save the entry; verify that the transaction
shows up on the list.
• Select the “delete” checkbox for the newly created
entry, click “delete all marked transactions”, and verify
that they’re gone.
• Create multiple transactions, check several of them and
delete; verify that tall selected transactions were indeed
deleted.
Acceptance Tests That Focus Too Much On Implementation
7/1/2016
6
Acceptance Tests(4): Trimmed Down
Version
• Try creating a new transaction
• Try deleting a transaction
• Try deleting multiple transactions
Customer Needs To Be Able To Understand Tests
7/1/2016
7
Understanding the Process
• The Acceptance TDD Cycle
–
–
–
–
Pick a Story
Write Tests for the Story
Automate the Tests
Implement the Functionality
• Acceptance TDD Inside an Iteration
–
–
–
–
Continuous Planning
Mid-Iteration Sanity Check
Decreasing The Load
Splitting Stories
A Process With Feedback
7/1/2016
8
TDD and Acceptance TDD
• Write a User Story
• Write Acceptance Test For Story
• Implement Acceptance Test
// Failing Acceptance Test
– Test, Code, Refactor
– Test, Code, Refactor
– Test, Code, Refactor
// Passing Acceptance Test
• Refactoring
• Customer Acceptance
Lather, Rinse, Repeat
7/1/2016
9
Acceptance Testing as a Team Activity
• Defining the Customer Role
–
–
–
–
Shared Interest in Success
Authority to Make Decisions
Ability to Understand Implications
Ability to Explain Domain
• Who Writes Tests With the Customer?
• How Many Testers Do We Need?
– One or Two Developers Per Tester
– Tester is a Role, Not a Job Title
Key Is Verification Against Target Domain
7/1/2016
10
Benefits of Acceptance Testing
• Definition of “Done”
– But Still Not Done Until “Simon Says” So
– Knowing Where We Are
– Knowing When to Stop
• Cooperative Work
• Trust and Commitment
• Specification By Example
– This is a Big One!
• Filling the Gap
– Unit Tests Are Not The Same As Acceptance Tests
Both Unit and Acceptance Tests Needed
7/1/2016
11
What Are We Testing, Exactly?
• Should We Test Against the UI?
– Do Whatever Is Easier Long Term
– Often UIs Are In the Way
– Not a Question Of Technology
• Capture Replay Tools Can Automate Tests
– Performance Might Matter
• Should We Stub Our System?
– Sufficiently Close To The Real Thing
– Sometimes Stubs Are Necessary
• Should We Test Business Logic Directly?
– Of Course – It’s What The Customer Cares About
Tests Need to Run Early
7/1/2016
12
Brief Overview of Available Tools
• Table-Based Frameworks
– Fit: Smart Parsing for Simple Tables
– FitNesse: Fit in a Wiki
– Selenium: Controlling a Browser
• Text-Based Frameworks
– Exactor: Simple Keyword-Driven Testing
– TextTest: Testing With Logs
• Scripting Language-Based Frameworks
• Homegrown Tools
Tool Support Is Essential
7/1/2016
13