Stephens Rosenberg Design Driven Testing Companion eBook Available 7.5 x 9.25 spine = 0.84375" 368 page count Matt Stephens and Doug Rosenberg Program and test from the same design Design Driven Testing Test Smarter, Not Harder THE EXPERT’S VOICE ® IN PROGRAMMING this print for content only—size & color not accurate CYAN MAGENTA YELLOW BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS ® Shelve in: Systems Analysis User level: Intermediate–Advanced www.apress.com SOURCE CODE ONLINE Companion eBook See last page for details on $10 eBook version ISBN 978-1-4302-2943-8 9 781430 229438 5 49 9 9 THE APRESS ROADMAP Design Driven Testing Agile Development with ICONIX Process Use Case Driven Object Modeling with UML Matt Stephens and Doug Rosenberg Co-authors of Extreme Programming Refactored: The Case Against XP Agile Development with ICONIX Process Use Case Driven Object Modeling with UML Design Driven Testing Dear Reader, Somebody’s got it backwards. Test Driven Development (TDD) tells us to write unit tests before writing code. We say that’s just backwards, not to mention that it’s Too Damn Difficult. In this book we use a real-life project to demonstrate that driving tests from the design (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 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 of the project lifecycle. DDT includes large amounts of automated support for generating test cases for all messages on a sequence diagram, and then transforming those test cases to JUnit, NUnit, or FlexUnit test code, and for automatically expanding all permuta- tions of sunny-day/rainy-day scenarios into a series of acceptance tests. The tech- niques and automated transforms we describe in this book will help you to “test smarter, not harder” on your projects. Matt Stephens and Doug Rosenberg Design Driven Testing is the fourth book that Matt and Doug have co-authored, following Extreme Programming Refactored, Agile Development with ICONIX Process, and Use Case Driven Object Modeling, Theory and Practice. www.it-ebooks.info www.it-ebooks.info i Design Driven Testing Test Smarter, Not Harder ■ ■ ■ Matt Stephens Doug Rosenberg www.it-ebooks.info ii 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 (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www.springeronline.com. For information on translations, please e-mail rights@apress.com, 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. www.it-ebooks.info iii www.it-ebooks.info iv 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 www.it-ebooks.info v 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 www.it-ebooks.info ■ CONTENTS vi ■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 www.it-ebooks.info ■ CONTENTS vii 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 www.it-ebooks.info ■ CONTENTS viii 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 www.it-ebooks.info [...]... creation and maintenance of both unit and acceptance tests based on and driven by the software design This is design- driven testing (DDT) This is leveraging your design to pinpoint where critical tests need to be based on the design and object behavior This is not test -driven design (TDD), where unit tests are written up front, before design is complete and coding starts I don’t know about you, but I think... 250 The Rebooted Design and Code 251 Summary 252 x www.it-ebooks.info ■ CONTENTS ■Chapter 11: Automated Integration Testing .253 Top-Ten Integration Testing “To-Do” List 254 10 Look for Test Patterns in Your Conceptual Design 254 9 Don’t Forget Security Tests 256 Security Testing: SQL Injection Attacks 256 Security Testing: Set Up... code is created equal, and some code benefits more from test coverage than other code.1 There just had to be a better way to benefit from automated testing Design- Driven Testing (DDT) was the result: a fusion of up-front analysis and design with an agile, test -driven mindset In many ways it’s a reversal of the thinking behind TDD, which is why we had some fun with the name But still, somebody obviously... can be calmed down and given some stability by first applying the up-front design and testing techniques described in this book The code is the design and the tests are the documentation The design is the design, the code is the code, and the tests are the tests With DDT, you’ll use modern development tools to keep the documented design model in sync with the code 10 www.it-ebooks.info CHAPTER 1 ■ SOMEBODY... benefit from additional tests We cover design- driven algorithm testing in Chapter 12 6 Kent Beck’s description of this was “a waterfall run through a blender.” 11 www.it-ebooks.info CHAPTER 1 ■ SOMEBODY HAS IT BACKWARDS TDD ICONIX/DDT After making a test pass, review the design and refactor the code if you think it’s needed With DDT, design churn” is minimized because the design is thought through with a... conceptual design, you can test smarter instead of harder.” This is a book about testing; not just QA-style visual inspection, but also automated testing driving unit tests, controller tests, and scenario tests from your design and the customer’s requirements As such, there’s bound to be some crossover between the techniques described in this book and what people set out to do with test -driven development... Singleton Design Pattern 218 5 The Tightly Bound Dependency 221 4 Business Logic in the UI Code 223 3 Privates on Parade 224 2 Service Objects That Are Declared Final 225 1 Half-Baked Features from the Good Deed Coder 225 Summary 226 ■Chapter 10: Design for Easier Testing .227 Top Ten Design for Testing ... crannies of development, and provides early feedback on the state of your code and the design Testing Badly Designed Code Is Hard It sounds obvious, but code that is badly designed tends to be rigid, difficult to adapt or re-use in some other context, and full of side effects By contrast, DDT inherently promotes good design and wellwritten, easily testable code This all makes it extremely difficult to... give up, having come to the conclusion that unit testing is too hard It’s a widespread problem, so we devote Chapter 9 to the problem of difficult-to-test code, and look at just why particular coding styles and design patterns make unit testing difficult It’s Easy to Forget Customer-Level Tests TDD is, by its nature, all about testing at the detailed design level We hate to say it, but in its separation... Between TDD and ICONIX/DDT TDD ICONIX/DDT Tests are used to drive the design of the application With DDT it’s the other way around: the tests are driven from the design, and, therefore, the tests are there primarily to validate the design That said, there’s more common ground between the two processes than you might think A lot of the design churn” (aka refactoring) to be found in TDD projects can be . acceptance tests based on and driven by the software design. This is design- driven testing (DDT). This is leveraging your design to pinpoint where critical. the design (and the requirements) is easier, more rigorous, and much more rewarding. Design Driven Testing (DDT) has a strong focus on both unit testing