Design Driven Testing: Test Smarter, Not Harder
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.
we’re also automatically generating test cases against the requirements. So the benefits of DDT vs. TDD are beginning to emerge, which, we hope, will benefit you on your own project: • The tools support will help make sure you don’t forget any requirements. • You’ll get broader test coverage, focusing in on all the “behavior points” of the use case. • You’ll be validating functional requirements in addition to testing the design. • You’ll be able to do all of the preceding very quickly.
model regularly to keep it in-sync with the code. 3. Keep the acceptance test scripts in-sync with the requirements. CHAPTER 4 ■ INTRODUCING THE MAPPLET PROJECT 2. Keep the automated tests up-to-date. 1. Compare the release candidate with the original use cases. As you can see, this list forms something of a high-level roadmap of “best practices” for your software project. Steps 5, 6 and 9 are the main focus of Part 2, so we won’t cover them in this chapter. The remaining steps (which
During the OOAD process, your domain model will evolve into a detailed design: the domain objects become entity classes, with attributes (the data) and operations (the behavior) allocated to each entity (we recommend allocating behavior to classes according to a “responsibility-driven” thought process).2 As we’re focusing on Quick Search and Advanced Search, let’s take a closer look at the detailed design for those two use cases. 1 We demonstrate domain-driven design in the context of use cases
box. The user clicks “Find.” The system searches for hotels within the current AOI, and filters the results according to the Hotel Filter Criteria, producing a Hotel Collection. Invoke Display Hotels on Map and Display Hotels on List Widget. 139 CHAPTER 6 ■ CONCEPTUAL DESIGN AND CONTROLLER TESTING ALTERNATE COURSES: Check-out date prior to check-in date: The system displays the user-error dialog “Check-out date prior to Check-in date.” Check-in date prior to today: The system displays the
has a test method called checkInDateEarlierThanToday(). ■ Note The original test case had a question mark in its name (“Dates are correct?”). We’ve manually removed the question mark from the test class, although we hope that a near-future release of EA will strip out noncompiling characters from class names automatically. 153 CHAPTER 6 ■ CONCEPTUAL DESIGN AND CONTROLLER TESTING Figure 6–10. The generated test class If you selected the “Generate Code on result” check box, you’ll already be