- Copyright
- Foreword
- About the Author
- About the Technical Reviewers
- Acknowledgments
- Prologue
- 1. DDT vs. TDD
- 1. Somebody Has It Backwards
- 2. TDD Using Hello World
- 2.1. Top Ten Characteristics of TDD
- 2.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 TDD
- 2.3. Acceptance Testing with TDD
- 2.4. Conclusion: TDD = Too Damn Difficult
- 2.5. Summary
- 2.1. Top Ten Characteristics of TDD
- 3. "Hello World!" Using DDT
- 3.1. Top Ten Features of ICONIX/DDT
- 3.1.1. 10. DDT Includes Business Requirement Tests
- 3.1.2. 9. DDT Includes Scenario Tests
- 3.1.3. 8. Tests Are Driven from Design
- 3.1.4. 7. DDT Includes Controller Tests
- 3.1.5. 6. DDT Tests Smarter, Not Harder
- 3.1.6. 5. DDT Unit Tests Are "Classical" Unit Tests
- 3.1.7. 4. DDT Test Cases Can Be Transformed into Test Code
- 3.1.8. 3. DDT Test Cases Lead to Test Plans
- 3.1.9. 2. DDT Tests Are Useful to Developers and QA Teams
- 3.1.10. 1. DDT Can Eliminate Redundant Effort
- 3.2. Login Implemented Using DDT
- 3.2.1. Step 1: Create a Robustness Diagram
- 3.2.2. Step 2: Create Controller Test Cases
- 3.2.3. Step 3: Add Scenarios
- 3.2.4. Step 4: Transform Controller Test Cases into Classes
- 3.2.5. Step 5: Generate Controller Test Code
- 3.2.6. Step 6: Draw a Sequence Diagram
- 3.2.7. Step 7: Create Unit Test Cases
- 3.2.8. Step 8: Fill in the Test Code
- 3.3. Summary
- 3.1. Top Ten Features of ICONIX/DDT
- 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 Practices
- 4.2. 10. Create an Architecture
- 4.3. 9. Agree on Requirements, and Test Against Them
- 4.4. 8. Drive Your Design from the Problem Domain
- 4.5. 7. Write Use Cases Against UI Storyboards
- 4.6. 6. Write Scenario Tests to Verify That the Use Cases Work
- 4.7. 5. Test Against Conceptual and Detailed Designs
- 4.8. 4. Update the Model Regularly
- 4.9. 3. Keep Test Scripts In-Sync with Requirements
- 4.10. 2. Keep Automated Tests Up to Date
- 4.11. 1. Compare the Release Candidate with Original Use Cases
- 4.12. Summary
- 5. Detailed Design and Unit Testing
- 5.1. Top Ten Unit Testing "To Do"s
- 5.1.1. 10. Start with a Sequence Diagram
- 5.1.2. 9. Identify Test Cases from Your Design
- 5.1.3. 8. Write Scenarios for Each Test Case
- 5.1.4. 7. Test Smarter: Avoid Overlapping Tests
- 5.1.5. 6. Transform Your Test Cases into UML Classes
- 5.1.6. 5. Write Unit Tests and Accompanying Code
- 5.1.7. 4. Write White Box Unit Tests
- 5.1.8. 3. Use a Mock Object Framework
- 5.1.9. 2. Test Algorithmic Logic with Unit Tests
- 5.1.10. 1. Write a Separate Suite of Integration Tests
- 5.2. Summary
- 5.1. Top Ten Unit Testing "To Do"s
- 6. Conceptual Design and Controller Testing
- 6.1. Top Ten Controller Testing "To-Do" List
- 6.1.1. 10. Start with a Robustness Diagram
- 6.1.2. 9. Identify Test Cases from Your Controllers
- 6.1.3. 8. Define One or More Scenarios per Test Case
- 6.1.4. 7. Fill in Description, Input, and Acceptance Criteria
- 6.1.5. 6. Generate Test Classes
- 6.1.6. 5. Implement the Tests
- 6.1.7. 4. Write Code That's Easy to Test
- 6.1.8. 3. Write "Gray Box" Controller Tests
- 6.1.9. 2. String Controller Tests Together
- 6.1.10. 1. Write a Separate Suite of Integration Tests
- 6.2. Summary
- 6.1. Top Ten Controller Testing "To-Do" List
- 7. Acceptance Testing: Expanding Use Case Scenarios
- 7.1. Top Ten Scenario Testing "To-Do" List
- 7.2. Mapplet Use Cases
- 7.2.1. 10. Start with a Narrative Use Case
- 7.2.2. 9. Transform to a Structured Scenario
- 7.2.3. 8. Make Sure All Paths Have Steps
- 7.2.4. 7. Add Pre-conditions and Post-conditions
- 7.2.5. 6. Generate an Activity Diagram
- 7.2.6. 5. Expand "Threads" Using "Create External Tests"
- 7.2.7. 4. Put the Test Case on a Test Case Diagram
- 7.2.8. 3. Drill into the EA Testing View
- 7.2.9. 2. Add Detail to the Test Scenarios
- 7.2.10. 1. Generate a Test Plan Document
- 7.3. And the Moral of the Story Is . . .
- 7.4. Summary
- 8. Acceptance Testing: Business Requirements
- 8.1. Top Ten Requirements Testing "To-Do" List
- 8.1.1. 10. Start with a Domain Model
- 8.1.2. 9. Write Business Requirement Tests
- 8.1.3. 8. Model and Organize Requirements
- 8.1.4. 7. Create Test Cases from Requirements
- 8.1.5. 6. Review Your Plan with the Customer
- 8.1.6. 5. Write Manual Test Scripts
- 8.1.7. 4. Write Automated Requirements Tests
- 8.1.8. 3. Export the Test Cases
- 8.1.9. 2. Make the Test Cases Visible
- 8.1.10. 1. Involve Your Team!
- 8.2. Summary
- 8.1. Top Ten Requirements Testing "To-Do" List
- 4. Introducing the Mapplet Project
- 3. Advanced DDT
- 9. Unit Testing Antipatterns (The "Don'ts")
- 9.1. The Temple of Doom (aka The Code)
- 9.2. The Antipatterns
- 9.2.1. 10. The Complex Constructor
- 9.2.2. 9. The Stratospheric Class Hierarchy
- 9.2.3. 8. The Static Hair-Trigger
- 9.2.4. 7. Static Methods and Variables
- 9.2.5. 6. The Singleton Design Pattern
- 9.2.6. 5. The Tightly Bound Dependency
- 9.2.7. 4. Business Logic in the UI Code
- 9.2.8. 3. Privates on Parade
- 9.2.9. 2. Service Objects That Are Declared Final
- 9.2.10. 1. Half-Baked Features from the Good Deed Coder
- 9.3. Summary
- 10. Design for Easier Testing
- 10.1. Top Ten "Design for Testing" To-Do List
- 10.2. The Temple of Doom—Thoroughly Expurgated
- 10.3. Design for Easier Testing
- 10.3.1. 10. Keep Initialization Code Out of the Constructor
- 10.3.2. 9. Use Inheritance Sparingly
- 10.3.3. 8. Avoid Using Static Initializer Blocks
- 10.3.4. 7. Use Object-Level Methods and Variables
- 10.3.5. 6. Avoid the Singleton Design Pattern
- 10.3.6. 5. Keep Your Classes Decoupled
- 10.3.7. 4. Keep Business Logic Out of the UI Code
- 10.3.8. 3. Use Black Box and Gray Box Testing
- 10.3.9. 2. Reserve the "Final" Modifier for Constants—Generally Avoid Marking Complex Types Such as Service Objects as Final
- 10.3.10. 1. Stick to the Use Cases and the Design
- 10.4. Detailed Design for the Quote Hotel Price Use Case
- 10.5. Summary
- 11. Automated Integration Testing
- 11.1. Top-Ten Integration Testing "To-Do" List
- 11.2. 10. Look for Test Patterns in Your Conceptual Design
- 11.3. 9. Don't Forget Security Tests
- 11.4. 8. Decide the "Level" of Integration Test to Write
- 11.5. 7. Drive Unit/Controller-Level Tests from Conceptual Design
- 11.6. 6. Drive Scenario Tests from Use Case Scenarios
- 11.7. 5. Write End-to-End Scenario Tests
- 11.8. 4. Use a "Business-Friendly" Testing Framework
- 11.9. 3. Test GUI Code as Part of Your Scenario Tests
- 11.10. 2. Don't Underestimate the Difficulty of Integration Testing
- 11.11. 1. Don't Underestimate the Value of Integration Tests
- 11.12. Key Points When Writing Integration Tests
- 11.13. Summary
- 12. Unit Testing Algorithms
- 12.1. Top Ten Algorithm Testing "To-Do"s
- 12.1.1. 10. Start with a Controller from the Conceptual Design
- 12.1.2. 9. Expand the Controllers into an Algorithm Design
- 12.1.3. 8. Tie the Diagram Loosely to Your Domain Model
- 12.1.4. 7. Split Up Decision Nodes Involving More Than One Check
- 12.1.5. 6. Create a Test Case for Each Node
- 12.1.6. 5. Define Test Scenarios for Each Test Case
- 12.1.7. 4. Create Input Data from a Variety of Sources
- 12.1.8. 3. Assign the Logic Flow to Individual Methods and Classes
- 12.1.9. 2. Write "White Box" Unit Tests
- 12.1.10. 1. Apply DDT to Other Design Diagrams
- 12.2. Summary
- 12.1. Top Ten Algorithm Testing "To-Do"s
- A. Alice in Use-Case Land
- A.1.
- A.2. Introduction
- A.3. Part 1
- A.3.1. Alice Falls Asleep While Reading
- A.3.2. The Promise of Use Case Driven Development
- A.3.3. An Analysis Model Links Use-Case Text with Objects
- A.3.4. Simple and Straightforward
- A.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 Code
- A.3.8. Abstract... Essential
- A.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 2
- A.4.1. Alice Gets Thirsty
- A.4.2. Alice Feels Faint
- A.4.3. Imagine... (with Apologies to John Lennon)
- A.4.4. Pair Programming Means Never Writing Down Requirements
- A.4.5. There's No Time to Write Down Requirements
- A.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 Terminated
- A.4.9. OnceAndOnlyOnce?
- A.4.10. Alice Refuses to Start Coding Without Written Requirements
- A.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 Design
- A.5. Part 3
- 'Twas Brillig and the Slithy Tests. . .
- 9. Unit Testing Antipatterns (The "Don'ts")
Beware the agile hype
| T'was brillig when the YAGNI'd code |
| did build itself ten times a day. |
| All flimsy were the index cards, |
| designs refactored clear away. |
| Beware the agile hype, my son |
| more code that smells, more bugs to catch. |
| Refactoring seem'd much more fun |
| until thy skills were overmatch'd. |
| With vorpal unit tests in hand |
| against the manxome bugs he fought. |
| Quite dazed was he by TDD, |
| some sanity was what he sought. |
| But, in his timebox made of wood, |
| determined by some planning game, |
| yon tests ran green and all was good |
| until the deadline came. |
| It's half past two, I guess we're through |
| it's time to have a tasty snack. |
| What's that you said, some tests ran red |
| all fixed, with one quick hack! |
| And lo the thought came with a shock, |
| design comes first, not tests, O joy! |
| We found upon this frabjous day |
| a simpl'r process to employ. |
| T'was brillig when the YAGNI'd code |
| did build itself ten times a day. |
| All flimsy were the index cards, |
| designs refactored clear away. . . |
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.