Design Driven Testing: Test Smarter, Not Harder

Prelim......Page 1
Contents at a Glance......Page 6
Contents......Page 7
Foreword......Page 16
About the Authors......Page 17
About the Technical Reviewers......Page 18
Acknowledgments......Page 19
Prologue......Page 20
DDT vs. TDD......Page 21
Somebody Has It Backwards......Page 23
Knowing When You’re Done Is Hard......Page 24
It’s Easy to Forget Customer-Level Tests......Page 25
Structure of DDT......Page 26
DDT in Action......Page 29
How TDD and DDT Differ......Page 30
Example Project: Introducing the Mapplet 2.0......Page 32
Summary......Page 35
TDD Using Hello World......Page 37
8. Everything is a unit test.......Page 38
5. TDD lends confidence to make changes.......Page 39
1. TDD is Too Damn Difficult.......Page 40
Understand the Requirement......Page 41
Think About the Design......Page 44
Write the First Test-First Test First......Page 45
Write the Login Check Code to Make the Test Pass......Page 49
Create a Mock Object......Page 52
Refactor the Code to See the Design Emerge......Page 54
Acceptance Testing with TDD......Page 60
Conclusion: TDD = Too Damn Difficult......Page 61
Summary......Page 62
“Hello World!” Using DDT......Page 63
8. Tests Are Driven from Design......Page 64
3. DDT Test Cases Lead to Test Plans......Page 65
Login Implemented Using DDT......Page 66
Step 1: Create a Robustness Diagram......Page 68
Step 2: Create Controller Test Cases......Page 72
Step 3: Add Scenarios......Page 75
Step 4: Transform Controller Test Cases into Classes......Page 77
Step 5: Generate Controller Test Code......Page 80
Step 6: Draw a Sequence Diagram......Page 83
Step 7: Create Unit Test Cases......Page 86
Step 8: Fill in the Test Code......Page 92
Summary......Page 95
DDT in the Real World: Mapplet 2.0 Travel Web Site......Page 99
Introducing the Mapplet Project......Page 101
Top Ten ICONIX Process/DDT Best Practices......Page 102
10. Create an Architecture......Page 103
9. Agree on Requirements, and Test Against Them......Page 104
8. Drive Your Design from the Problem Domain......Page 106
Map......Page 108
7. Write Use Cases Against UI Storyboards......Page 109
6. Write Scenario Tests to Verify That the Use Cases Work......Page 111
4. Update the Model Regularly......Page 115
3. Keep Test Scripts In-Sync with Requirements......Page 122
1. Compare the Release Candidate with Original Use Cases......Page 123
Summary......Page 127
Detailed Design and Unit Testing......Page 129
Top Ten Unit Testing “To Do”s......Page 130
10. Start with a Sequence Diagram......Page 131
9. Identify Test Cases from Your Design......Page 133
8. Write Scenarios for Each Test Case......Page 135
7. Test Smarter: Avoid Overlapping Tests......Page 137
6. Transform Your Test Cases into UML Classes......Page 138
Writing the “No Hotels” Test......Page 143
Implementing SearchHotelService......Page 144
4. Write White Box Unit Tests......Page 146
Implement a Stunt Service......Page 147
Update the Test Code to Use the Stunt Service......Page 150
The Stunt Service Approach......Page 151
The Mock Object Framework Approach......Page 152
1. Write a Separate Suite of Integration Tests......Page 154
Summary......Page 156
Conceptual Design and Controller Testing......Page 157
The Use Case......Page 159
Conceptual Design from Which to Drive Controller Tests......Page 160
9. Identify Test Cases from Your Controllers......Page 163
Identifying the Input Values for a Test Scenario......Page 166
Using EA to Create Test Scenarios......Page 168
7. Fill in Description, Input, and Acceptance Criteria......Page 169
Before Generating Your Tests......Page 170
Generating the Tests......Page 172
5. Implement the Tests......Page 175
4. Write Code That’s Easy to Test......Page 176
3. Write “Gray Box” Controller Tests......Page 178
2. String Controller Tests Together......Page 179
1. Write a Separate Suite of Integration Tests......Page 181
Summary......Page 182
Acceptance Testing: Expanding Use Case Scenarios......Page 183
Top Ten Scenario Testing “To-Do” List......Page 184
Mapplet Use Cases......Page 185
10. Start with a Narrative Use Case......Page 186
9. Transform to a Structured Scenario......Page 190
8. Make Sure All Paths Have Steps......Page 191
6. Generate an Activity Diagram......Page 192
5. Expand “Threads” Using “Create External Tests”......Page 194
4. Put the Test Case on a Test Case Diagram......Page 195
3. Drill into the EA Testing View......Page 196
1. Generate a Test Plan Document......Page 197
And the Moral of the Story Is . . .......Page 199
Summary......Page 202
Acceptance Testing: Business Requirements......Page 203
Top Ten Requirements Testing “To-Do” List......Page 204
10. Start with a Domain Model......Page 205
9. Write Business Requirement Tests......Page 207
8. Model and Organize Requirements......Page 208
7. Create Test Cases from Requirements......Page 212
6. Review Your Plan with the Customer......Page 214
3. Export the Test Cases......Page 218
1. Involve Your Team!......Page 219
Summary......Page 220
Advanced DDT......Page 221
Unit Testing Antipatterns (The “Don’ts”)......Page 223
The Temple of Doom (aka The Code)......Page 224
The Big Picture......Page 225
The HotelPriceCalculator Class......Page 226
Supporting Classes......Page 228
Service Classes......Page 229
10. The Complex Constructor......Page 231
9. The Stratospheric Class Hierarchy......Page 233
8. The Static Hair-Trigger......Page 235
7. Static Methods and Variables......Page 237
6. The Singleton Design Pattern......Page 238
5. The Tightly Bound Dependency......Page 241
4. Business Logic in the UI Code......Page 243
3. Privates on Parade......Page 244
1. Half-Baked Features from the Good Deed Coder......Page 245
Summary......Page 246
Design for Easier Testing......Page 247
Top Ten “Design for Testing” To-Do List......Page 248
The Use Case—Figuring Out What We Want to Do......Page 249
Identify the Controller Tests......Page 252
Calculate Overall Price Test......Page 253
Retrieve Latest Price Test......Page 254
10. Keep Initialization Code Out of the Constructor......Page 255
9. Use Inheritance Sparingly......Page 256
8. Avoid Using Static Initializer Blocks......Page 257
6. Avoid the Singleton Design Pattern......Page 258
5. Keep Your Classes Decoupled......Page 260
4. Keep Business Logic Out of the UI Code......Page 261
3. Use Black Box and Gray Box Testing......Page 266
2. Reserve the “Final” Modifier for Constants—Generally Avoid Marking Complex Types Such as Service Objects as Final......Page 267
Detailed Design for the Quote Hotel Price Use Case......Page 268
Controller Test: Retrieve Latest Price Test......Page 270
The Rebooted Design and Code......Page 271
Summary......Page 272
Automated Integration Testing......Page 273
10. Look for Test Patterns in Your Conceptual Design......Page 274
Security Testing: SQL Injection Attacks......Page 276
Security Testing: Set Up Secure Sessions......Page 277
Knowing Which Level of Integration Test to Write......Page 278
7. Drive Unit/Controller-Level Tests from Conceptual Design......Page 279
6. Drive Scenario Tests from Use Case Scenarios......Page 282
Emulating the Steps in a Scenario......Page 283
Sharing a Test Database......Page 284
A Vanilla xUnit Scenario Test......Page 286
4. Use a “Business-Friendly” Testing Framework......Page 287
3. Test GUI Code as Part of Your Scenario Tests......Page 289
2. Don’t Underestimate the Difficulty of Integration Testing......Page 290
Database Metadata Changes......Page 292
Cloudy Days......Page 293
Key Points When Writing Integration Tests......Page 294
Summary......Page 296
Unit Testing Algorithms......Page 297
Top Ten Algorithm Testing “To-Do”s......Page 298
10. Start with a Controller from the Conceptual Design......Page 299
9. Expand the Controllers into an Algorithm Design......Page 301
8. Tie the Diagram Loosely to Your Domain Model......Page 303
6. Create a Test Case for Each Node......Page 304
5. Define Test Scenarios for Each Test Case......Page 306
4. Create Input Data from a Variety of Sources......Page 309
3. Assign the Logic Flow to Individual Methods and Classes......Page 310
2. Write “White Box” Unit Tests......Page 315
Testing the “At least one candidate returned” Decision Node......Page 316
Testing the “Exactly one candidate or one is a 100% match” Decision Node......Page 317
Send in the Spy Object......Page 320
Break the Code into Smaller Methods......Page 325
1. Apply DDT to Other Design Diagrams......Page 326
Summary......Page 327
Introduction......Page 329
Part 1......Page 330
An Analysis Model Links Use-Case Text with Objects......Page 331
We’re Late! We Have to Start Coding!......Page 332
Teleocentricity.........Page 333
Are We Really Supposed to Specify All This for Every Use Case?......Page 334
Alice Gets Thirsty......Page 336
Imagine... (with Apologies to John Lennon)......Page 337
Pair Programming Means Never Writing Down Requirements......Page 338
You Might As Well Say, “The Code Is the Design”......Page 339
Who Cares for Use Cases?......Page 340
C3 Project Terminated......Page 341
Alice Refuses to Start Coding Without Written Requirements......Page 343
You Are Guilty of BDUF.........Page 344
Some Serious Refactoring of the Design......Page 345
Part 3......Page 346
Behavior Allocation Happens on Sequence Diagrams......Page 347
And the Moral of That Is…......Page 348
’Twas Brillig and the Slithy Tests…......Page 349
Index......Page 353