book

Design Driven Testing: Test Smarter, Not Harder

Name: Design Driven Testing: Test Smarter, Not Harder
ISBN: 9781430229438

by Matt Stephens, Doug Rosenberg

September 2010

Intermediate to advanced

362 pages

English

Apress

Read now

Unlock full access

Copyright
Foreword
About the Author
About the Technical Reviewers
Acknowledgments
Prologue
1. DDT vs. TDD
1. Somebody Has It Backwards
1.1. Problems DDT Sets Out to Solve1.1.1. Knowing When You're Done Is Hard1.1.2. Leaving Testing Until Later Costs More1.1.3. Testing Badly Designed Code Is Hard1.1.4. It's Easy to Forget Customer-Level Tests1.1.5. Developers Become Complacent1.1.6. Tests Sometimes Lack Purpose1.2. A Quick, Tools-Agnostic Overview of DDT1.2.1. Structure of DDT1.2.2. DDT in Action1.3. How TDD and DDT Differ1.4. Example Project: Introducing the Mapplet 2.01.5. Summary
2. TDD Using Hello World
2.1. Top Ten Characteristics of TDD2.1.1. 10. Tests drive the design.2.1.2. 9. There is a Total Dearth of Documentation.2.1.3. 8. Everything is a unit test.2.1.4. 7. TDD tests are not quite unit tests (or are they?).2.1.5. 6. Acceptance tests provide feedback against the requirements.2.1.6. 5. TDD lends confidence to make changes.2.1.7. 4. Design emerges incrementally.2.1.8. 3. Some up-front design is OK.2.1.9. 2. TDD produces a lot of tests.2.1.10. 1. TDD is Too Damn Difficult.2.2. Login Implemented Using TDD2.2.1. Understand the Requirement2.2.2. Think About the Design2.2.3. Write the First Test-First Test First2.2.4. Write the Login Check Code to Make the Test Pass2.2.5. Create a Mock Object2.2.6. Refactor the Code to See the Design Emerge2.3. Acceptance Testing with TDD2.4. Conclusion: TDD = Too Damn Difficult2.5. Summary
3. "Hello World!" Using DDT
3.1. Top Ten Features of ICONIX/DDT3.1.1. 10. DDT Includes Business Requirement Tests3.1.2. 9. DDT Includes Scenario Tests3.1.3. 8. Tests Are Driven from Design3.1.4. 7. DDT Includes Controller Tests3.1.5. 6. DDT Tests Smarter, Not Harder3.1.6. 5. DDT Unit Tests Are "Classical" Unit Tests3.1.7. 4. DDT Test Cases Can Be Transformed into Test Code3.1.8. 3. DDT Test Cases Lead to Test Plans3.1.9. 2. DDT Tests Are Useful to Developers and QA Teams3.1.10. 1. DDT Can Eliminate Redundant Effort3.2. Login Implemented Using DDT3.2.1. Step 1: Create a Robustness Diagram3.2.2. Step 2: Create Controller Test Cases3.2.3. Step 3: Add Scenarios3.2.4. Step 4: Transform Controller Test Cases into Classes3.2.5. Step 5: Generate Controller Test Code3.2.6. Step 6: Draw a Sequence Diagram3.2.7. Step 7: Create Unit Test Cases3.2.8. Step 8: Fill in the Test Code3.3. Summary

2. DDT in the Real World: Mapplet 2.0 Travel Web Site
4. Introducing the Mapplet Project
4.1. Top Ten ICONIX Process/DDT Best Practices4.2. 10. Create an Architecture4.3. 9. Agree on Requirements, and Test Against Them4.4. 8. Drive Your Design from the Problem Domain4.5. 7. Write Use Cases Against UI Storyboards4.6. 6. Write Scenario Tests to Verify That the Use Cases Work4.7. 5. Test Against Conceptual and Detailed Designs4.8. 4. Update the Model Regularly4.9. 3. Keep Test Scripts In-Sync with Requirements4.10. 2. Keep Automated Tests Up to Date4.11. 1. Compare the Release Candidate with Original Use Cases4.12. Summary
5. Detailed Design and Unit Testing
5.1. Top Ten Unit Testing "To Do"s5.1.1. 10. Start with a Sequence Diagram5.1.2. 9. Identify Test Cases from Your Design5.1.3. 8. Write Scenarios for Each Test Case5.1.4. 7. Test Smarter: Avoid Overlapping Tests5.1.5. 6. Transform Your Test Cases into UML Classes5.1.6. 5. Write Unit Tests and Accompanying Code5.1.6.1. Writing the "No Hotels" Test5.1.6.2. Implementing SearchHotelService5.1.7. 4. Write White Box Unit Tests5.1.7.1. Implement a Stunt Service5.1.7.2. Update the Test Code to Use the Stunt Service5.1.8. 3. Use a Mock Object Framework5.1.8.1. The Stunt Service Approach5.1.8.2. The Mock Object Framework Approach5.1.9. 2. Test Algorithmic Logic with Unit Tests5.1.10. 1. Write a Separate Suite of Integration Tests5.2. Summary
6. Conceptual Design and Controller Testing
6.1. Top Ten Controller Testing "To-Do" List6.1.1. 10. Start with a Robustness Diagram6.1.1.1. The Use Case6.1.1.2. Conceptual Design from Which to Drive Controller Tests6.1.2. 9. Identify Test Cases from Your Controllers6.1.3. 8. Define One or More Scenarios per Test Case6.1.3.1. Understanding Test Scenarios6.1.3.2. Identifying the Input Values for a Test Scenario6.1.3.3. Using EA to Create Test Scenarios6.1.4. 7. Fill in Description, Input, and Acceptance Criteria6.1.5. 6. Generate Test Classes6.1.5.1. Before Generating Your Tests6.1.5.2. Generating the Tests6.1.6. 5. Implement the Tests6.1.7. 4. Write Code That's Easy to Test6.1.8. 3. Write "Gray Box" Controller Tests6.1.9. 2. String Controller Tests Together6.1.10. 1. Write a Separate Suite of Integration Tests6.2. Summary
7. Acceptance Testing: Expanding Use Case Scenarios
7.1. Top Ten Scenario Testing "To-Do" List7.2. Mapplet Use Cases7.2.1. 10. Start with a Narrative Use Case7.2.2. 9. Transform to a Structured Scenario7.2.3. 8. Make Sure All Paths Have Steps7.2.4. 7. Add Pre-conditions and Post-conditions7.2.5. 6. Generate an Activity Diagram7.2.6. 5. Expand "Threads" Using "Create External Tests"7.2.7. 4. Put the Test Case on a Test Case Diagram7.2.8. 3. Drill into the EA Testing View7.2.9. 2. Add Detail to the Test Scenarios7.2.10. 1. Generate a Test Plan Document7.3. And the Moral of the Story Is . . .7.4. Summary
8. Acceptance Testing: Business Requirements
8.1. Top Ten Requirements Testing "To-Do" List8.1.1. 10. Start with a Domain Model8.1.2. 9. Write Business Requirement Tests8.1.3. 8. Model and Organize Requirements8.1.4. 7. Create Test Cases from Requirements8.1.5. 6. Review Your Plan with the Customer8.1.6. 5. Write Manual Test Scripts8.1.7. 4. Write Automated Requirements Tests8.1.8. 3. Export the Test Cases8.1.9. 2. Make the Test Cases Visible8.1.10. 1. Involve Your Team!8.2. Summary
3. Advanced DDT
9. Unit Testing Antipatterns (The "Don'ts")
9.1. The Temple of Doom (aka The Code)9.1.1. The Big Picture9.1.2. The HotelPriceCalculator Class9.1.3. Supporting Classes9.1.4. Service Classes9.2. The Antipatterns9.2.1. 10. The Complex Constructor9.2.2. 9. The Stratospheric Class Hierarchy9.2.3. 8. The Static Hair-Trigger9.2.4. 7. Static Methods and Variables9.2.5. 6. The Singleton Design Pattern9.2.6. 5. The Tightly Bound Dependency9.2.7. 4. Business Logic in the UI Code9.2.8. 3. Privates on Parade9.2.9. 2. Service Objects That Are Declared Final9.2.10. 1. Half-Baked Features from the Good Deed Coder9.3. Summary
10. Design for Easier Testing
10.1. Top Ten "Design for Testing" To-Do List10.2. The Temple of Doom—Thoroughly Expurgated10.2.1. The Use Case—Figuring Out What We Want to Do10.2.2. Identify the Controller Tests10.2.3. Calculate Overall Price Test10.2.4. Retrieve Latest Price Test10.3. Design for Easier Testing10.3.1. 10. Keep Initialization Code Out of the Constructor10.3.2. 9. Use Inheritance Sparingly10.3.3. 8. Avoid Using Static Initializer Blocks10.3.4. 7. Use Object-Level Methods and Variables10.3.5. 6. Avoid the Singleton Design Pattern10.3.6. 5. Keep Your Classes Decoupled10.3.7. 4. Keep Business Logic Out of the UI Code10.3.8. 3. Use Black Box and Gray Box Testing10.3.9. 2. Reserve the "Final" Modifier for Constants—Generally Avoid Marking Complex Types Such as Service Objects as Final10.3.10. 1. Stick to the Use Cases and the Design10.4. Detailed Design for the Quote Hotel Price Use Case10.4.1. Controller Test: Calculate Overall Price10.4.2. Controller Test: Retrieve Latest Price Test10.4.3. The Rebooted Design and Code10.5. Summary
11. Automated Integration Testing
11.1. Top-Ten Integration Testing "To-Do" List11.2. 10. Look for Test Patterns in Your Conceptual Design11.3. 9. Don't Forget Security Tests11.3.1. Security Testing: SQL Injection Attacks11.3.2. Security Testing: Set Up Secure Sessions11.4. 8. Decide the "Level" of Integration Test to Write11.4.1. How the Three Levels Differ11.4.2. Knowing Which Level of Integration Test to Write11.5. 7. Drive Unit/Controller-Level Tests from Conceptual Design11.6. 6. Drive Scenario Tests from Use Case Scenarios11.7. 5. Write End-to-End Scenario Tests11.7.1. Emulating the Steps in a Scenario11.7.2. Sharing a Test Database11.7.3. Mapplet Example: The "Advanced Search" Use Case11.7.4. A Vanilla xUnit Scenario Test11.8. 4. Use a "Business-Friendly" Testing Framework11.9. 3. Test GUI Code as Part of Your Scenario Tests11.10. 2. Don't Underestimate the Difficulty of Integration Testing11.10.1. Network Latency11.10.2. Database Metadata Changes11.10.3. Randomly Mutating (aka "Agile") Interfaces11.10.4. Bugs in the Remote System11.10.5. Cloudy Days11.11. 1. Don't Underestimate the Value of Integration Tests11.12. Key Points When Writing Integration Tests11.13. Summary
12. Unit Testing Algorithms
12.1. Top Ten Algorithm Testing "To-Do"s12.1.1. 10. Start with a Controller from the Conceptual Design12.1.2. 9. Expand the Controllers into an Algorithm Design12.1.3. 8. Tie the Diagram Loosely to Your Domain Model12.1.4. 7. Split Up Decision Nodes Involving More Than One Check12.1.5. 6. Create a Test Case for Each Node12.1.6. 5. Define Test Scenarios for Each Test Case12.1.7. 4. Create Input Data from a Variety of Sources12.1.8. 3. Assign the Logic Flow to Individual Methods and Classes12.1.9. 2. Write "White Box" Unit Tests12.1.9.1. Testing the "At least one candidate returned" Decision Node12.1.9.2. Testing the "Exactly one candidate or one is a 100% match" Decision Node12.1.9.3. Send in the Spy Object12.1.9.3.1. Spy Object 001: SpyList12.1.9.3.2. Spy Object 002: SpyAddressCandidate12.1.9.4. Break the Code into Smaller Methods12.1.10. 1. Apply DDT to Other Design Diagrams12.2. Summary
A. Alice in Use-Case Land
A.1.A.1.1.A.1.1.1. It's Not as Surreal as You Might Think . . .A.2. IntroductionA.3. Part 1A.3.1. Alice Falls Asleep While ReadingA.3.2. The Promise of Use Case Driven DevelopmentA.3.3. An Analysis Model Links Use-Case Text with ObjectsA.3.4. Simple and StraightforwardA.3.5. <<includes>> or <<extends>>A.3.6. We're Late! We Have to Start Coding!A.3.7. Alice Wonders How to Get from Use Cases to CodeA.3.8. Abstract... EssentialA.3.9. A Little Too Abstract?A.3.10. Teleocentricity...A.3.11. Are We Really Supposed to Specify All This for Every Use Case?A.4. Part 2A.4.1. Alice Gets ThirstyA.4.2. Alice Feels FaintA.4.3. Imagine... (with Apologies to John Lennon)A.4.4. Pair Programming Means Never Writing Down RequirementsA.4.5. There's No Time to Write Down RequirementsA.4.6. You Might As Well Say, "The Code Is the Design"A.4.7. Who Cares for Use Cases?A.4.8. C3 Project TerminatedA.4.9. OnceAndOnlyOnce?A.4.10. Alice Refuses to Start Coding Without Written RequirementsA.4.11. You Are Guilty of BDUF...A.4.12. CMM's Dead! Off with Her Head!A.4.13. Some Serious Refactoring of the DesignA.5. Part 3A.5.1. Alice Wakes UpA.5.2. Closing the Gap Between "What" and "How"A.5.3. Static and Dynamic Models Are Linked TogetherA.5.4. Behavior Allocation Happens on Sequence DiagramsA.5.5. And the Moral of That Is...
'Twas Brillig and the Slithy Tests. . .

Content preview from Design Driven Testing: Test Smarter, Not Harder

Chapter 1. Somebody Has It Backwards

The first time we saw a description of Test-Driven Development (TDD), our immediate thought was: "That's just backwards!" Wanting to give the process the benefit of the doubt, Matt went ahead and put TDD into practice on his own projects, attended seminars, kept up with the latest test-driven trends, and so forth. But the nagging feeling was still there that it just didn't feel right to drive the design from the tests. There was also the feeling that TDD is highly labor-intensive, luring developers into an expensive and ultimately futile chase for the holy grail of 100% test coverage. Not all code is created ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781430229438Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Design Driven Testing: Test Smarter, Not Harder

by Matt Stephens, Doug Rosenberg

Chapter 1. Somebody Has It Backwards

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.