Test Driven Lasse Koskela Chapter 9 Acceptance TDD

  • Slides: 13
Download presentation
Test Driven Lasse Koskela Chapter 9: Acceptance TDD Explained Paul Ammann http: //cs. gmu.

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

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? 3/12/2021 2

Introduction To User Stories • Format of a Story – As a (role) I

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. 3/12/2021 3

Acceptance Tests • Example Tests For a Story • Properties of Acceptance Tests –

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 3/12/2021 4

Acceptance Tests(2): Example Stories • Simulate a call with Fred’s account number and verify

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 3/12/2021 5

Acceptance Tests(3): Too Much Information • Go to the “new transaction” screen, fill in

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 3/12/2021 6

Acceptance Tests(4): Trimmed Down Version • Try creating a new transaction • Try deleting

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 3/12/2021 7

Understanding the Process • The Acceptance TDD Cycle – – Pick a Story Write

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 3/12/2021 8

TDD and Acceptance TDD • Write a User Story • Write Acceptance Test For

TDD and Acceptance TDD • Write a User Story • Write Acceptance Test For Story • Implement Acceptance Test // Failing Acceptance Test – Test, Code, Refactor // Passing Acceptance Test • Refactoring • Customer Acceptance Lather, Rinse, Repeat 3/12/2021 9

Acceptance Testing as a Team Activity • Defining the Customer Role – – Shared

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 3/12/2021 10

Benefits of Acceptance Testing • Definition of “Done” – But Still Not Done Until

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 3/12/2021 11

What Are We Testing, Exactly? • Should We Test Against the UI? – Do

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 3/12/2021 12

Brief Overview of Available Tools • Table-Based Frameworks – Fit: Smart Parsing for Simple

Brief Overview of Available Tools • Table-Based Frameworks – Fit: Smart Parsing for Simple Tables – Fit. Nesse: Fit in a Wiki – Selenium: Controlling a Browser • Text-Based Frameworks – Exactor: Simple Keyword-Driven Testing – Text. Test: Testing With Logs • Scripting Language-Based Frameworks • Homegrown Tools Tool Support Is Essential 3/12/2021 13