Design Driven Testing: Test Smarter, Not Harder

Design Driven Testing: Test Smarter, Not Harder

Matt Stephens

Language: English

Pages: 368

ISBN: 1430229438

Format: PDF / Kindle (mobi) / ePub


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.

.net [UK] (March 2015)

World Bank and Urban Development: From Projects to Policy (Routledge Studies in Development and Society)

Professional jQuery

jQuery Pocket Reference

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

■About the Technical Reviewers ..........................................................................xvi ■Acknowledgments .............................................................................................xvii ■Prologue ...........................................................................................................xviii Part 1: DDT vs. TDD...................................................................................................1 ■Chapter 1: Somebody Has It

of software development, with analysis/design/development activities on the left, and testing activities on the right. With a little wrangling, DDT actually fits this model pretty well, as we show in Figure 1–3. Figure 1–3. V model of development adapted to DDT 3 So (you might well be wondering), how do I decide whether to cover a method with a unit test or a controller test? Simple—implement the controller tests first; if there’s any “significant” (nonboilerplate) code left uncovered,

“No Hotels” test scenario, then we could simply make callSearchService(HotelFilter) return an empty XML document. But—it’s that precognitive dissonance kicking in again 6—we know from the design that there’s also going to be a “Return Some 6 128 It’s almost as if developers were capable of forethought and planning… CHAPTER 5 ■ DETAILED DESIGN AND UNIT TESTING Hotels” test. So we’ve added a slightly sneaky method, setFakeXmlResponse(xml), which the unit tests can call before the service is

solely for this purpose. Update the Test Code to Use the Stunt Service We need to update the unit test to pass in the new stunt service client. We’ll do this in the setUp() code: StuntServiceClient stuntClient; SearchHotelService searchService; @Before public void setUp() throws Exception { stuntClient = new StuntServiceClient(); searchService = new SearchHotelService(); searchService.setServiceClient(stuntClient); } To mitigate possible memory leakage, we’ll also un-set the fixtures when the

effective at identifying the “control points” in your design that want to be tested the most. To learn about robustness diagrams in the context of the ICONIX Process and DDT, we suggest you read this book’s companion volume, Use Case Driven Object Modeling with UML: Theory and Practice. 3 An example Flex design pattern that helps you achieve this is “Code Behind”: www.insideria.com/2010/05/code-behind-vs-template-compon.html. 141 CHAPTER 6 ■ CONCEPTUAL DESIGN AND CONTROLLER TESTING Figure

Download sample

Download