Design Driven Testing: Test Smarter, Not Harder

365 Pages·12.523 MB·English

by  Doug Rosenberg, Matt Stephens

CYAN YELLOW
MAGENTA BLACK
PANTONE 123 C
BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN PROGRAMMING
Companion
eBook
Available
Design Driven Testing
D
Dear Reader, e
Somebody’s got it backwards. s
Test Driven Development (TDD) tells us to write unit tests before writing code.
Design Driven
We say that’s just backwards, not to mention that it’s Too Damn Difficult. In this i
book we use a real-life project to demonstrate that driving tests from the design g
(and the requirements) is easier, more rigorous, and much more rewarding.
Design Driven Testing (DDT) has a strong focus on both unit testing (done by n
developers) and acceptance testing (done by an independent QA team). In this
book we’ll show you how to create maintainable tests that are broader in scope
than TDD-style unit tests. You’ll learn a feedback-driven approach for each stage D
Testing
of the project lifecycle.
DDT includes large amounts of automated support for generating test cases
r
for all messages on a sequence diagram, and then transforming those test cases to
i
JUnit, NUnit, or FlexUnit test code, and for automatically expanding all permuta-
Matt Stephens and v
tions of sunny-day/rainy-day scenarios into a series of acceptance tests. The tech-
Doug Rosenberg
niques and automated transforms we describe in this book will help you to “test
e
Co-authors of smarter, not harder” on your projects.
Extreme Programming
n Test Smarter, Not Harder
Refactored: The Case Matt Stephens and Doug Rosenberg
Against XP

Agile Development with Design Driven Testing is the fourth book that Matt and Doug have co-authored,
T
ICONIX Process following Extreme Programming Refactored, Agile Development with ICONIX
Use Case Driven Object Process, and Use Case Driven Object Modeling, Theory and Practice. e
Modeling with UML
s
THE APRESS ROADMAP t
Companion eBook
i Program and test from the same design
Use Case
Driven Object Modeling Agile Development Design n
with ICONIX Process Driven Testing
with UML
g

See last page for details
on $10 eBook version
SOURCE CODE ONLINE R
www.apress.com osSt Matt Stephens and Doug Rosenberg
ee
ISBN 978-1-4302-2943-8 np
bh
54999 ee
rn
Shelve in: gs

Systems Analysis
User level:
Intermediate–Advanced
9 781430 229438
this print for content only—size & color not accurate 7.5 x 9.25 spine = 0.84375" 368 page count

Design Driven Testing
Test Smarter, Not Harder

■ ■ ■
Matt Stephens
Doug Rosenberg

i
Design Driven Testing: Test Smarter, Not Harder
Copyright © 2010 by Matt Stephens and Doug Rosenberg
All rights reserved. No part of this work may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying, recording, or by any
information storage or retrieval system, without the prior written permission of the copyright
owner and the publisher.
ISBN-13 (pbk): 978-1-4302-2943-8
ISBN-13 (electronic): 978-1-4302-2944-5
Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1
Trademarked names, logos, and images may appear in this book. Rather than use a trademark
symbol with every occurrence of a trademarked name, logo, or image we use the names,
logos, and images only in an editorial fashion and to the benefit of the trademark owner, with
no intention of infringement of the trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even
if they are not identified as such, is not to be taken as an expression of opinion as to whether
or not they are subject to proprietary rights.
President and Publisher: Paul Manning
Lead Editor: Jonathan Gennick
Technical Reviewer: Jeffrey Kantor and David Putnam
Editorial Board: Clay Andres, Steve Anglin, Mark Beckner, Ewan Buckingham, Gary
Cornell, Jonathan Gennick, Jonathan Hassell, Michelle Lowman, Matthew Moodie,
Duncan Parkes, Jeffrey Pepper, Frank Pohlmann, Douglas Pundick, Ben Renow-Clarke,
Dominic Shakeshaft, Matt Wade, Tom Welsh
Coordinating Editor: Anita Castro
Copy Editor: Mary Ann Fugate
Compositor: MacPS, LLC
Indexer: BIM Indexing & Proofreading Services
Artist: April Milne
Cover Designer: Anna Ishchenko
Distributed to the book trade worldwide by Springer Science+Business Media, LLC, 233 Spring
Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax [phone], e-mail
[email protected], or visit www.springeronline.com.
For information on translations, please e-mail [email protected], or visit www.apress.com.
Apress and friends of ED books may be purchased in bulk for academic, corporate, or
promotional use. eBook versions and licenses are also available for most titles. For more
information, reference our Special Bulk Sales–eBook Licensing web page at
www.apress.com/info/bulksales.
The information in this book is distributed on an “as is” basis, without warranty. Although
every precaution has been taken in the preparation of this work, neither the author(s) nor
Apress shall have any liability to any person or entity with respect to any loss or damage
caused or alleged to be caused directly or indirectly by the information contained in this work.
ii
iii
Contents at a Glance

■ Contents.................................................................................................................v
■ Foreword............................................................................................................xiv
■ About the Authors................................................................................................xv
■ About the Technical Reviewers..........................................................................xvi
■ Acknowledgments.............................................................................................xvii
■ Prologue...........................................................................................................xviii
Part 1: DDT vs. TDD...................................................................................................1
■ Chapter 1: Somebody Has It Backwards...............................................................3
■ Chapter 2: TDD Using Hello World........................................................................17
■ Chapter 3: “Hello World!” Using DDT...................................................................43
Part 2: DDT in the Real World: Mapplet 2.0 Travel Web Site......................................79
■ Chapter 4: Introducing the Mapplet Project........................................................81
■ Chapter 5: Detailed Design and Unit Testing.....................................................109
■ Chapter 6: Conceptual Design and Controller Testing.......................................137
■ Chapter 7: Acceptance Testing: Expanding Use Case Scenarios.......................163
■ Chapter 8: Acceptance Testing: Business Requirements..................................183
Part 3: Advanced DDT...........................................................................................201
■ Chapter 9: Unit Testing Antipatterns (The “Don’ts”).........................................203
■ Chapter 10: Design for Easier Testing...............................................................227
■ Chapter 11: Automated Integration Testing.......................................................253
■ Chapter 12: Unit Testing Algorithms..................................................................277
■ Appendix: Alice in Use-Case Land.....................................................................309
■ Epilogue: ’Twas Brillig and the Slithy Tests…..................................................329
■ Index..................................................................................................................333

iv
Contents

■ Contents at a Glance.............................................................................................iv
■ Foreword............................................................................................................xiv
■ About the Authors................................................................................................xv
■ About the Technical Reviewers..........................................................................xvi
■ Acknowledgments.............................................................................................xvii
■ Prologue...........................................................................................................xviii

Part 1: DDT vs. TDD...................................................................................................1
■ Chapter 1: Somebody Has It Backwards...............................................................3
Problems DDT Sets Out to Solve.....................................................................................4
Knowing When You’re Done Is Hard......................................................................................................4
Leaving Testing Until Later Costs More.................................................................................................5
Testing Badly Designed Code Is Hard....................................................................................................5
It’s Easy to Forget Customer-Level Tests..............................................................................................5
Developers Become Complacent...........................................................................................................5
Tests Sometimes Lack Purpose............................................................................................................6
A Quick, Tools-Agnostic Overview of DDT......................................................................6
Structure of DDT....................................................................................................................................6
DDT in Action.........................................................................................................................................9
How TDD and DDT Differ...............................................................................................10
Example Project: Introducing the Mapplet 2.0..............................................................12
Summary......................................................................................................................15

v
■ CONTENTS
■ Chapter 2: TDD Using Hello World........................................................................17
Top Ten Characteristics of TDD....................................................................................18
10. Tests drive the design...................................................................................................................18
9. There is a Total Dearth of Documentation.......................................................................................18
8. Everything is a unit test...................................................................................................................18
7. TDD tests are not quite unit tests (or are they?)..............................................................................19
6. Acceptance tests provide feedback against the requirements.......................................................19
5. TDD lends confidence to make changes.........................................................................................19
4. Design emerges incrementally........................................................................................................20
3. Some up-front design is OK.............................................................................................................20
2. TDD produces a lot of tests.............................................................................................................20
1. TDD is Too Damn Difficult................................................................................................................20
Login Implemented Using TDD.....................................................................................21
Understand the Requirement...............................................................................................................21
Think About the Design.......................................................................................................................24
Write the First Test-First Test First......................................................................................................25
Write the Login Check Code to Make the Test Pass............................................................................29
Create a Mock Object..........................................................................................................................32
Refactor the Code to See the Design Emerge.....................................................................................34
Acceptance Testing with TDD.......................................................................................40
Conclusion: TDD = Too Damn Difficult..........................................................................41
Summary......................................................................................................................42
■ Chapter 3: “Hello World!” Using DDT...................................................................43
Top Ten Features of ICONIX/DDT..................................................................................44
10. DDT Includes Business Requirement Tests...................................................................................44
9. DDT Includes Scenario Tests...........................................................................................................44
8. Tests Are Driven from Design..........................................................................................................44
7. DDT Includes Controller Tests.........................................................................................................45
6. DDT Tests Smarter, Not Harder.......................................................................................................45
5. DDT Unit Tests Are “Classical” Unit Tests.......................................................................................45
4. DDT Test Cases Can Be Transformed into Test Code......................................................................45
vi
C O■NTENTS
3. DDT Test Cases Lead to Test Plans.................................................................................................45
2. DDT Tests Are Useful to Developers and QA Teams........................................................................45
1. DDT Can Eliminate Redundant Effort...............................................................................................46
Login Implemented Using DDT.....................................................................................46
Step 1: Create a Robustness Diagram.................................................................................................48
Step 2: Create Controller Test Cases...................................................................................................52
Step 3: Add Scenarios.........................................................................................................................55
Step 4: Transform Controller Test Cases into Classes.........................................................................57
Step 5: Generate Controller Test Code................................................................................................60
Step 6: Draw a Sequence Diagram......................................................................................................63
Step 7: Create Unit Test Cases............................................................................................................66
Step 8: Fill in the Test Code.................................................................................................................72
Summary......................................................................................................................75
Part 2: DDT in the Real World: Mapplet 2.0 Travel Web Site......................................79
■ Chapter 4: Introducing the Mapplet Project........................................................81
Top Ten ICONIX Process/DDT Best Practices................................................................82
10. Create an Architecture............................................................................................83
9. Agree on Requirements, and Test Against Them.....................................................84
8. Drive Your Design from the Problem Domain...........................................................86
7. Write Use Cases Against UI Storyboards..................................................................89
6. Write Scenario Tests to Verify That the Use Cases Work..........................................91
5. Test Against Conceptual and Detailed Designs........................................................95
4. Update the Model Regularly.....................................................................................95
3. Keep Test Scripts In-Sync with Requirements.......................................................102
2. Keep Automated Tests Up to Date..........................................................................103
1. Compare the Release Candidate with Original Use Cases......................................103
Summary....................................................................................................................107
■ Chapter 5: Detailed Design and Unit Testing.....................................................109
Top Ten Unit Testing “To Do”s...................................................................................110
10. Start with a Sequence Diagram...................................................................................................111
9. Identify Test Cases from Your Design............................................................................................113
vii
■ CONTENTS
8. Write Scenarios for Each Test Case...............................................................................................115
7. Test Smarter: Avoid Overlapping Tests.........................................................................................117
6. Transform Your Test Cases into UML Classes...............................................................................118
5. Write Unit Tests and Accompanying Code.....................................................................................123
4. Write White Box Unit Tests............................................................................................................126
3. Use a Mock Object Framework......................................................................................................131
2. Test Algorithmic Logic with Unit Tests..........................................................................................134
1. Write a Separate Suite of Integration Tests...................................................................................134
Summary....................................................................................................................136
■ Chapter 6: Conceptual Design and Controller Testing.......................................137
Top Ten Controller Testing “To-Do” List.....................................................................139
10. Start with a Robustness Diagram................................................................................................139
9. Identify Test Cases from Your Controllers.....................................................................................143
8. Define One or More Scenarios per Test Case................................................................................146
7. Fill in Description, Input, and Acceptance Criteria........................................................................149
6. Generate Test Classes...................................................................................................................150
5. Implement the Tests......................................................................................................................155
4. Write Code That’s Easy to Test......................................................................................................156
3. Write “Gray Box” Controller Tests.................................................................................................158
2. String Controller Tests Together....................................................................................................159
1. Write a Separate Suite of Integration Tests...................................................................................161
Summary....................................................................................................................162
■ Chapter 7: Acceptance Testing: Expanding Use Case Scenarios.......................163
Top Ten Scenario Testing “To-Do” List......................................................................164
Mapplet Use Cases.....................................................................................................165
10. Start with a Narrative Use Case...................................................................................................166
9. Transform to a Structured Scenario..............................................................................................170
8. Make Sure All Paths Have Steps...................................................................................................171
7. Add Pre-conditions and Post-conditions.......................................................................................172
6. Generate an Activity Diagram........................................................................................................172
5. Expand “Threads” Using “Create External Tests”.........................................................................174
viii