Design Driven Testing (eBook)

Test Smarter, Not Harder

Matt Stephens, Doug Rosenberg (Autoren)

eBook Download: PDF

2011 | 1st ed.
XVIII, 368 Seiten
Apress (Verlag)
978-1-4302-2944-5 (ISBN)

Infos

The groundbreaking book Design Driven Testing brings sanity back to the software development process by flipping around the concept of Test Driven Development (TDD)-restoring the concept of using testing to verify a design instead of pretending that unit tests are a replacement for design. Anyone who feels that TDD is 'Too Damn Difficult' will appreciate this book.

Design Driven Testing shows that, by combining a forward-thinking development process with cutting-edge automation, testing can be a finely targeted, business-driven, rewarding effort. In other words, you'll learn how to test smarter, not harder.

• Applies a feedback-driven approach to each stage of the project lifecycle.
• Illustrates a lightweight and effective approach using a core subset of UML.
• Follows a real-life example project using Java and Flex/ActionScript.
• Presents bonus chapters for advanced DDTers covering unit-test antipatterns (and their opposite, 'test-conscious' design patterns), and showing how to create your own test transformation templates in Enterprise Architect.

Matt Stephens is a Java developer, project leader, and technical architect with a financial organization based in central London. He's been developing software commercially for over 15 years, and has led many agile projects through successive customer releases. He has spoken at a number of software conferences on object-oriented development topics, and his writing appears regularly in a variety of software journals and websites, including The Register and ObjectiveView. Matt is the co-author of Extreme Programming Refactored: The Case Against XP (Apress, 2003) with Doug Rosenberg, Agile Development with ICONIX Process (Apress, 2005) with Doug Rosenberg and Mark Collins-Cope, and Use Case Driven Object Modeling with UML: Theory and Practice with Doug Rosenberg (Apress, 2007). Catch Matt online at www.softwarereality.com.

---

In this chapter we illustrated how to drive unit tests from a software design, identifying test scenarios in a systematic way that ensures the code is covered in all the right places. We also illustrated the use of "e;stunt services"e; and mock objects to isolate the code being tested; finally, we discussed driving unit tests deeper into algorithmic code that may benefit from finer-grained testing. Is there a way to get 95% of the benefit of the comprehensive unit testing we did in this chapter with significantly fewer tests? In the next chapter, we'll show how to do exactly that with controller tests. As you'll see, unit tests do have their place, but controller tests can often represent a smarter, more structured approach to application testing. 136 C H A P T E R 6 ? ? ? Conceptual Design and Controller Testing As you saw in Chapter 5, unit testing doesn't have to involve exhaustively covering every single line of code, or even every single method, with tests. There's a law of diminishing returns-and increasing difficulty-as you push the code coverage percentile ever higher. By taking a step back and looking at the design on a broader scale, it's possible to pick out the key areas of code that act as input/output junctures, and focus the tests on those areas.

Inhalt

Title Page 1
Copyright Page 2
Contents at a Glance 3
Table of contents 4
Foreword 13
About the Authors 14
About the Technical Reviewers 15
Acknowledgments 16
Prologue 17
Part 1: DDT vs. TDD 18
Chapter 1: Somebody Has It Backwards 20
Problems DDT Sets Out to Solve 21
Knowing When You’re Done Is Hard 21
Leaving Testing Until Later Costs More 22
Testing Badly Designed Code Is Hard 22
It’s Easy to Forget Customer-Level Tests 22
Developers Become Complacent 23
Tests Sometimes Lack Purpose 23
A Quick, Tools-Agnostic Overview of DDT 23
Structure of DDT 23
DDT in Action 26
How TDD and DDT Differ 27
Example Project: Introducing the Mapplet 2.0 29
Summary 32
Chapter 2: TDD Using Hello World 34
Top Ten Characteristics of TDD 35
10. Tests drive the design. 35
9. There is a Total Dearth of Documentation. 35
8. Everything is a unit test 35
7. TDD tests are not quite unit tests (or are they?) 36
6. Acceptance tests provide feedback against the requirements. 36
5. TDD lends confidence to make changes. 36
4. Design emerges incrementally 37
3. Some up-front design is OK 37
2. TDD produces a lot of tests. 37
1. TDD is Too Damn Difficult 37
Login Implemented Using TDD 38
Understand the Requirement 38
Think About the Design 41
Write the First Test-First Test First 42
Write the Login Check Code to Make the Test Pass 46
Create a Mock Object 49
Refactor the Code to See the Design Emerge 51
Acceptance Testing with TDD 57
Conclusion: TDD = Too Damn Difficult 58
Summary 59
Chapter 3: “Hello World!” Using DDT 60
Top Ten Features of ICONIX/DDT 61
10. DDT Includes Business Requirement Tests 61
9. DDT Includes Scenario Tests 61
8. Tests Are Driven from Design 61
7. DDT Includes Controller Tests 62
6. DDT Tests Smarter, Not Harder 62
5. DDT Unit Tests Are “Classical” Unit Tests 62
4. DDT Test Cases Can Be Transformed into Test Code 62
3. DDT Test Cases Lead to Test Plans 62
2. DDT Tests Are Useful to Developers and QA Teams 63
1. DDT Can Eliminate Redundant Effort 63
Login Implemented Using DDT 63
Step 1: Create a Robustness Diagram 65
Step 2: Create Controller Test Cases 69
Step 3: Add Scenarios 72
Step 4: Transform Controller Test Cases into Classes 74
Step 5: Generate Controller Test Code 77
Step 6: Draw a Sequence Diagram 80
Step 7: Create Unit Test Cases 83
Step 8: Fill in the Test Code 89
Summary 92
Part 2: DDT in the Real World: Mapplet 2.0 Travel Web Site 95
Chapter 4: Introducing the Mapplet Project 97
Top Ten ICONIX Process/DDT Best Practices 98
10. Create an Architecture 99
9. Agree on Requirements, and Test Against Them 100
8. Drive Your Design from the Problem Domain 102
7. Write Use Cases Against UI Storyboards 105
6. Write Scenario Tests to Verify That the Use Cases Work 107
5. Test Against Conceptual and Detailed Designs 111
4. Update the Model Regularly 111
3. Keep Test Scripts In-Sync with Requirements 118
2. Keep Automated Tests Up to Date 119
1. Compare the Release Candidate with Original Use Cases 119
Summary 123
Chapter 5: Detailed Design and Unit Testing 124
Top Ten Unit Testing “To Do”s 125
10. Start with a Sequence Diagram 126
9. Identify Test Cases from Your Design 128
8. Write Scenarios for Each Test Case 130
7. Test Smarter: Avoid Overlapping Tests 132
6. Transform Your Test Cases into UML Classes 133
5. Write Unit Tests and Accompanying Code 138
Writing the “No Hotels” Test 138
Implementing SearchHotelService 139
4. Write White Box Unit Tests 141
Implement a Stunt Service 142
Update the Test Code to Use the Stunt Service 145
3. Use a Mock Object Framework 146
The Stunt Service Approach 146
The Mock Object Framework Approach 147
2. Test Algorithmic Logic with Unit Tests 149
1. Write a Separate Suite of Integration Tests 149
Summary 151
Chapter 6: Conceptual Design and Controller Testing 152
Top Ten Controller Testing “To-Do” List 154
10. Start with a Robustness Diagram 154
The Use Case 154
Conceptual Design from Which to Drive Controller Tests 155
9. Identify Test Cases from Your Controllers 158
8. Define One or More Scenarios per Test Case 161
Understanding Test Scenarios 161
Identifying the Input Values for a Test Scenario 161
Using EA to Create Test Scenarios 163
7. Fill in Description, Input, and Acceptance Criteria 164
6. Generate Test Classes 165
Before Generating Your Tests 165
Generating the Tests 167
5. Implement the Tests 170
4. Write Code That’s Easy to Test 171
3. Write “Gray Box” Controller Tests 173
2. String Controller Tests Together 174
1. Write a Separate Suite of Integration Tests 176
Summary 177
Chapter 7: Acceptance Testing: Expanding Use Case Scenarios 178
Top Ten Scenario Testing “To-Do” List 179
Mapplet Use Cases 180
10. Start with a Narrative Use Case 181
9. Transform to a Structured Scenario 185
8. Make Sure All Paths Have Steps 186
7. Add Pre-conditions and Post-conditions 187
6. Generate an Activity Diagram 187
5. Expand “Threads” Using “Create External Tests” 189
4. Put the Test Case on a Test Case Diagram 190
3. Drill into the EA Testing View 191
2. Add Detail to the Test Scenarios 192
1. Generate a Test Plan Document 192
And the Moral of the Story Is . . . 194
Summary 197
Chapter 8: Acceptance Testing: Business Requirements 198
Top Ten Requirements Testing “To-Do” List 199
10. Start with a Domain Model 200
9. Write Business Requirement Tests 202
8. Model and Organize Requirements 203
7. Create Test Cases from Requirements 207
6. Review Your Plan with the Customer 209
5. Write Manual Test Scripts 213
4. Write Automated Requirements Tests 213
3. Export the Test Cases 213
2. Make the Test Cases Visible 214
1. Involve Your Team! 214
Summary 215
Part 3 Advanced DDT 216
Chapter 9: Unit Testing Antipatterns (The “Don’ts”) 218
The Temple of Doom (aka The Code) 219
The Big Picture 220
The HotelPriceCalculator Class 221
Supporting Classes 223
Service Classes 224
The Antipatterns 226
10. The Complex Constructor 226
9. The Stratospheric Class Hierarchy 228
8. The Static Hair-Trigger 230
7. Static Methods and Variables 232
6. The Singleton Design Pattern 233
5. The Tightly Bound Dependency 236
4. Business Logic in the UI Code 238
3. Privates on Parade 239
2. Service Objects That Are Declared Final 240
1. Half-Baked Features from the Good Deed Coder 240
Summary 241
Chapter 10: Design for Easier Testing 242
Top Ten “Design for Testing” To-Do List 243
The Temple of Doom—Thoroughly Expurgated 244
The Use Case—Figuring Out What We Want to Do 244
Identify the Controller Tests 247
Calculate Overall Price Test 248
Retrieve Latest Price Test 249
Design for Easier Testing 250
10. Keep Initialization Code Out of the Constructor 250
9. Use Inheritance Sparingly 251
8. Avoid Using Static Initializer Blocks 252
7. Use Object-Level Methods and Variables 253
6. Avoid the Singleton Design Pattern 253
5. Keep Your Classes Decoupled 255
4. Keep Business Logic Out of the UI Code 256
3. Use Black Box and Gray Box Testing 261
2. Reserve the “Final” Modifier for Constants—Generally Avoid Marking Complex Types Such as Service Objects as Final 262
1. Stick to the Use Cases and the Design 263
Detailed Design for the Quote Hotel Price Use Case 263
Controller Test: Calculate Overall Price 265
Controller Test: Retrieve Latest Price Test 265
The Rebooted Design and Code 266
Summary 267
Chapter 11: Automated Integration Testing 268
Top-Ten Integration Testing “To-Do” List 269
10. Look for Test Patterns in Your Conceptual Design 269
9. Don’t Forget Security Tests 271
Security Testing: SQL Injection Attacks 271
Security Testing: Set Up Secure Sessions 272
8. Decide the “Level” of Integration Test to Write 273
How the Three Levels Differ 273
Knowing Which Level of Integration Test to Write 273
7. Drive Unit/Controller-Level Tests from Conceptual Design 274
6. Drive Scenario Tests from Use Case Scenarios 277
5. Write End-to-End Scenario Tests 278
Emulating the Steps in a Scenario 278
Sharing a Test Database 279
Mapplet Example: The “Advanced Search” Use Case 281
A Vanilla xUnit Scenario Test 281
4. Use a “Business-Friendly” Testing Framework 282
3. Test GUI Code as Part of Your Scenario Tests 284
2. Don’t Underestimate the Difficulty of Integration Testing 285
Network Latency 287
Database Metadata Changes 287
Randomly Mutating (aka “Agile”) Interfaces 288
Bugs in the Remote System 288
Cloudy Days 288
1. Don’t Underestimate the Value of Integration Tests 289
Key Points When Writing Integration Tests 289
Summary 291
Chapter 12: Unit Testing Algorithms 292
Top Ten Algorithm Testing “To-Do”s 293
10. Start with a Controller from the Conceptual Design 294
9. Expand the Controllers into an Algorithm Design 296
8. Tie the Diagram Loosely to Your Domain Model 298
7. Split Up Decision Nodes Involving More Than One Check 299
6. Create a Test Case for Each Node 299
5. Define Test Scenarios for Each Test Case 301
4. Create Input Data from a Variety of Sources 304
3. Assign the Logic Flow to Individual Methods and Classes 305
2. Write “White Box” Unit Tests 310
Testing the “At least one candidate returned” Decision Node 311
Testing the “Exactly one candidate or one is a 100% match” Decision Node 312
Send in the Spy Object 315
Break the Code into Smaller Methods 320
1. Apply DDT to Other Design Diagrams 321
Summary 322
APPENDIX Alice in Use-Case Land 323
Introduction 323
Part 1 324
Alice Falls Asleep While Reading 325
The Promise of Use Case Driven Development 325
An Analysis Model Links Use-Case Text with Objects 325
Simple and Straightforward 326
< <
We’re Late! We Have to Start Coding! 326
Alice Wonders How to Get from Use Cases to Code 327
Abstract... Essential 327
A Little Too Abstract? 327
Teleocentricity... 327
Are We Really Supposed to Specify All This for Every Use Case? 328
Part 2 330
Alice Gets Thirsty 330
Alice Feels Faint 331
Imagine... (with Apologies to John Lennon) 331
Pair Programming Means Never Writing Down Requirements 332
There’s No Time to Write Down Requirements 333
You Might As Well Say, “The Code Is the Design” 333
Who Cares for Use Cases? 334
C3 Project Terminated 335
OnceAndOnlyOnce? 337
Alice Refuses to Start Coding Without Written Requirements 337
You Are Guilty of BDUF... 338
CMM’s Dead! Off with Her Head! 339
Some Serious Refactoring of the Design 339
Part 3 340
Alice Wakes Up 341
Closing the Gap Between “What” and “How” 341
Static and Dynamic Models Are Linked Together 341
Behavior Allocation Happens on Sequence Diagrams 341
And the Moral of That Is… 342
EPILOGUE ’Twas Brillig and the Slithy Tests… 343
Index 347

Produkt-Details

• Erscheint lt. Verlag: 11.1.2011
• Zusatzinfo: XVIII, 368 p.
• Verlagsort: Berkeley
• Sprache: englisch
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• Themenwelt: Informatik ► Software Entwicklung ► Qualität / Testen
• Schlagworte: algorithm • algorithms • Control • Design Pattern • Java • programming • unified modeling language (UML) • Unit Tests • Use Case
• ISBN-10: 1-4302-2944-6 / 1430229446
• ISBN-13: 978-1-4302-2944-5 / 9781430229445