nach oben

2010 | Buch

Kapitel lesen Erstes Kapitel lesen

Design Driven Testing

Test Smarter, Not Harder

verfasst von: Matt Stephens, Doug Rosenberg

Verlag: Apress

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

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.

Inhaltsverzeichnis

Frontmatter

DDT vs. TDD

Frontmatter

Chapter 1. Somebody Has It Backwards

Abstract

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 equal, and some code benefits more from test coverage than other code.1 There just had to be a better way to benefit from automated testing.

Matt Stephens, Doug Rosenberg

Chapter 2. TDD Using Hello World

Abstract

We continue our comparison of TDD and DDT techniques in this chapter, with a straightforward “Hello world!” example (actually a system login) performed using the TDD approach. Logging in seems strangely apt for a “Hello world!” example, as (a) it’s a simple concept and exists in virtually every serious IT application, and (b) it’s the system saying “Hello” to the user (and the user saying “Hello” back).

Matt Stephens, Doug Rosenberg

Chapter 3. “Hello World!” Using DDT

Abstract

In this chapter, Alice wakes up and wonders if her adventures through the TDD looking glass were all just a disturbing dream. Meanwhile we’ll hit Reboot on the Login example and start over, this time following DDT. We hope this will help to illustrate some of the key differences between the two approaches. In particular, DDT provides a systematic method of identifying, up-front, the critical areas of a design that will benefit the most from automated testing.

Matt Stephens, Doug Rosenberg

DDT in the Real World: Mapplet 2.0 Travel Web Site

Frontmatter

Chapter 4. Introducing the Mapplet Project

Abstract

It’s more difficult (and more time consuming) to base a book around a real software project than it is to write one with a toy example. For this book, though, we thought it was important to show how DDT works on the real thing, as we expect a bit of skepticism from test-driven developers. This chapter introduces you to our example project, which we call the Mapplet 2.0, and Chapters 5–8 will show how we’ve unit tested it (at two levels of abstraction) and how we’ve done acceptance testing against use-case scenarios and against the requirements. As you can see in the chapter-opener diagram, these two levels of developer testing and two levels of independent QA testing form the core of DDT.

Matt Stephens, Doug Rosenberg

Chapter 5. Detailed Design and Unit Testing

Abstract

“Detailed design” is when the team really starts to make the hard decisions about how the system will be implemented. The team may also be creating prototypes to explore various facets of the design and to help produce more realistic time/effort estimates; but, ultimately, they need to gain common consensus on how the system will be put together, with a clear design agreed upon and understood by all the members of the development team.

Matt Stephens, Doug Rosenberg

Chapter 6. Conceptual Design and Controller Testing

Abstract

As you saw in Chapter 5, unit testing doesn’t have to involve exhaustively covering every single line of code, or even every single method, with tests. There’s a law of diminishing returns—and increasing difficulty—as you push the code coverage percentile ever higher. By taking a step back and looking at the design on a broader scale, it’s possible to pick out the key areas of code that act as input/output junctures, and focus the tests on those areas.

Matt Stephens, Doug Rosenberg

Chapter 7. Acceptance Testing: Expanding Use Case Scenarios

Abstract

This is the first chapter where we leave the realm of programmer tests. As we walk backwards from completion and a delivered product, through coding, design, and unit/controller tests, we reach the analysis stage that is covered by acceptance tests written from the perspective of users, customers, and business analysts.

Matt Stephens, Doug Rosenberg

Chapter 8. Acceptance Testing: Business Requirements

Abstract

In this chapter, you’ll learn how to generate customer-facing business requirement tests from the requirements in your model, how to organize those tests, and how to generate a test plan document from them. To illustrate this, we’ll once again make use of the “Agile/ICONIX add-in” for Enterprise Architect.

Matt Stephens, Doug Rosenberg

Advanced DDT

Frontmatter

Chapter 9. Unit Testing Antipatterns (The “Don’ts”)

Abstract

The majority of software projects are ongoing affairs. New screens and functions are released on (or around) specific, agreed dates, but a project itself keeps chugging along. So it’s far more common for developers to join a project mid-flow, with its own dusty corners that no one dares to disturb, its homegrown object-relational mapping classes, crusted together with the foibles and wrinkles of a dozen long-since departed self-styled code gurus. Starting a brand new project from scratch is a rare joy: the opportunity to set the standards, consider the architecture, evaluate the available technologies given the business requirements, and produce clean, maintainable code that’s easily unit-tested.

Matt Stephens, Doug Rosenberg

Chapter 10. Design for Easier Testing

Abstract

In this chapter we emerge from the Temple of Doom to find the sun shining brightly and the water a lovely shade of turquoise…¹

Matt Stephens, Doug Rosenberg

Chapter 11. Automated Integration Testing

Abstract

Automated integration testing is a pig, but it’s an important pig. And it’s important for precisely the reasons it’s so difficult.

Matt Stephens, Doug Rosenberg

Chapter 12. Unit Testing Algorithms

Abstract

One of the main messages in this book has been “test smarter, not harder”—that is, write fewer tests that each cover more code. If done using the techniques we’ve described, you can actually improve your effective test coverage while having fewer test cases (but comparatively more test scenarios, or “inputs” and their “expected outputs,” for each test case).

Matt Stephens, Doug Rosenberg

Backmatter

Titel: Design Driven Testing
verfasst von: Matt Stephens
Doug Rosenberg
Verlag: Apress
Electronic ISBN: 978-1-4302-2944-5
Print ISBN: 978-1-4302-2943-8
DOI: https://doi.org/10.1007/978-1-4302-2944-5