xUnit Test Patterns: Refactoring Test Code

xUnit Test Patterns: Refactoring Test Code

Gerard Meszaros

Language: English

Pages: 833

ISBN: 0131495054

Format: PDF / Kindle (mobi) / ePub

Automated testing is a cornerstone of agile development. An effective testing strategy will deliver new functionality more aggressively, accelerate user feedback, and improve quality. However, for many developers, creating effective automated tests is a unique and unfamiliar challenge.

xUnit Test Patterns is the definitive guide to writing automated tests using xUnit, the most popular unit testing framework in use today. Agile coach and test automation expert Gerard Meszaros describes 68 proven patterns for making tests easier to write, understand, and maintain. He then shows you how to make them more robust and repeatable--and far more cost-effective.

Loaded with information, this book feels like three books in one. The first part is a detailed tutorial on test automation that covers everything from test strategy to in-depth test coding. The second part, a catalog of 18 frequently encountered "test smells," provides trouble-shooting guidelines to help you determine the root cause of problems and the most applicable patterns. The third part contains detailed descriptions of each pattern, including refactoring instructions illustrated by extensive code samples in multiple programming languages.

Topics covered include

Writing better tests--and writing them faster

The four phases of automated tests: fixture setup, exercising the system under test, result verification, and fixture teardown

Improving test coverage by isolating software from its environment using Test Stubs and Mock Objects

Designing software for greater testability

Using test "smells" (including code smells, behavior smells, and project smells) to spot problems and know when and how to eliminate them

This book will benefit developers, managers, and testers working with any agile or conventional development process, whether doing test-driven development or writing the tests last. While the patterns and smells are especially applicable to all members of the xUnit family, they also apply to next-generation behavior-driven development frameworks such as RSpec and JBehave and to other kinds of test automation tools, including recorded test tools and data-driven test tools such as Fit and FitNesse.

programmatically. We called this variant an Anonymous Creation Method (see Creation Method) to indicate the presence of this added behavior. Identifying the problem that we now call a Fragile Test (page 239) was an important event on this project, and the subsequent deﬁnition of its solution patterns saved this project from possible failure. Without this discovery we would, at best, have abandoned the automated unit tests that we had already built. At worst, the tests would have reduced our

Test Unit1 SUT Exercise Comp2 SUT Uses App1 SUT Figure I.1. A range of tests each with its own SUT. An application, component, or unit is only the SUT with respect to a speciﬁc set of tests. The “Unit1 SUT” plays the role of DOC (part of the ﬁxture) to “Unit2 Test” and is part of the “Comp1 SUT” and the “App1 SUT.” Using Java as the main sample language also means that in some discussions we will refer to the JUnit name of a method and will not list the corresponding method names in each of

numbers by using a Replace Magic Number with Symbolic Constant [Fowler] refactoring to give them roledescribing names. Also, the constructor we are using to create the LineItem is not used anywhere in the SUT itself because the LineItem normally calculates the extendedCost when it is constructed. We should turn this test-speciﬁc code into a Foreign Method [Fowler] implemented within the test harness. We have already seen examples of how to do so with the Customer and Product: We use a

tries to prevent bugs from being introduced. Think of automated tests as “bug repellent” that keeps nasty little bugs from crawling back into our software after we have made sure it doesn’t contain any bugs. Wherever we have regression tests, we won’t have bugs because the tests will point the bugs out before we even check in our code. (We are running all the tests before every check-in, aren’t we?) Goal: Defect Localization Mistakes happen! Of course, some mistakes are much more expensive to

automation. This chapter made the value system we use while choosing patterns explicit. In Chapter 6, Test Automation Strategy, we will examine the “hard to change” decisions that we should try to get right early in the project. Chapter 6 Test Automation Strategy About This Chapter In previous chapters, we saw some of the problems we might encounter with test automation. In Chapter 5, Principles of Test Automation, we learned about some of the principles we can apply to help address those