book

Design Driven Testing: Test Smarter, Not Harder

by Matt Stephens, Doug Rosenberg

September 2010

Intermediate to advanced

362 pages

English

Apress

Read now

Unlock full access

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.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.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

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.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.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.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.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
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.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.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.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.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...

Overview

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.

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.

Start your free trial

Managing Expectations: Working with People Who Want More, Better, Faster, Sooner, NOW!

Publisher Resources

ISBN: 9781430229438Purchase book

Design Driven Testing: Test Smarter, Not Harder

by Matt Stephens, Doug Rosenberg

Overview

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.

You might also like

Managing Expectations: Working with People Who Want More, Better, Faster, Sooner, NOW!

What Successful Project Managers Do

How to Become a Game-Changing Leader

How I Built a Personal Board of Directors With GenAI

Publisher Resources

Overview

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.

You might also like

Managing Expectations: Working with People Who Want More, Better, Faster, Sooner, NOW!

What Successful Project Managers Do

How to Become a Game-Changing Leader

How I Built a Personal Board of Directors With GenAI

Publisher Resources

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.