Meszaros G. xUnit Test Patterns Refactoring Test Code

Подождите немного. Документ загружается.

208

Chapter 15 Code Smells

readability issue can easily be addressed by using an Extract Method [Fowler]

refactoring to create a Parameterized Test call from within the loop. The lack

of Defect Localization can be addressed by calling the Parameterized Test

from a separate Test Method for each test condition. For large sets of values,

a Data-Driven Test (page 288) might be a better solution.

Conditional

Test Logic

209

Hard-to-Test Code

Code is difﬁ cult to test.

Automated testing is a powerful tool that helps us develop software quickly even

when we have a large code base to maintain. Of course, it provides these beneﬁ ts

only if most of our code is protected by Fully Automated Tests (see page 26). The

effort of writing these tests must be added to the effort of writing the product

code they verify. Not surprisingly, we would prefer to make it easy to write the

automated tests.

Hard-to-Test Code is one factor that makes it difﬁ cult to write complete,

correct automated tests in a cost-efﬁ cient manner.

Symptoms

Some kinds of code are inherently difﬁ cult to test—GUI components, multi-

threaded code, and test code, for example. It may be difﬁ cult to get at the code

to be tested because it is not visible to a test. It may be problematic to compile

a test because the code is too highly coupled to other classes. It may be hard to

create an instance of the object because the constructors don’t exist, are private,

or take too many other objects as parameters.

Impact

Whenever we have Hard-to-Test Code, we cannot easily verify the quality of

that code in an automated way. While manual quality assessment is often pos-

sible, it doesn’t scale very well because the effort to perform this assessment after

each code change usually means it doesn’t get done. Nor is this strategy readily

repeated without a large test documentation cost.

Solution Patterns

A better solution is to make the code more amenable to testing. This topic is big

enough that it warrants a whole chapter of its own, but this section covers a few

of the highlights.

We would also like to recoup this cost by reducing effort somewhere else. The best way

to achieve this is to avoid Frequent Debugging (page 248) by writing the tests ﬁ rst and

achieving Defect Localization (see page 22).

Hard-to-Test Code

Hard-to-Test

Code

210

Chapter 15 Code Smells

Causes

There are a number of reasons for Hard-to-Test Code; the most common causes

are discussed here.

Cause: Highly Coupled Code

Symptoms

A class cannot be tested without also testing several other classes.

Impact

Code that is highly coupled to other code is very difﬁ cult to unit test because it

won’t execute in isolation.

Root Cause

Highly Coupled Code can be caused by many factors, including poor design,

lack of object-oriented design experience, and lack of a reward structure that

encourages decoupling.

Possible Solution

The key to testing overly coupled code is to break the coupling. This happens

naturally when we are doing test-driven development.

A technique that we often use to decouple code for the purpose of testing is

a Test Double (page 522) or, more speciﬁ cally, a Test Stub (page 529) or Mock

Object (page 544). This topic is covered in much more detail in Chapter 11,

Using Test Doubles.

Retroﬁ tting tests onto existing code is a more challenging task, especially

when we are dealing with a legacy code base. This is a big enough topic that

Michael Feathers wrote a whole book on techniques for doing this, titled Work-

ing Effectively with Legacy Code [WEwLC].

Cause: Asynchronous Code

Symptoms

A class cannot be tested via direct method calls. The test must start an execut-

able (such as a thread, process, or application) and wait until its start-up has

ﬁ nished before interacting with the executable.

Hard-to-Test

Code

Also known as:

Hard-Coded

Dependency

211

Impact

Code that has an asynchronous interface is hard to test because the tests of these

elements must coordinate their execution with that of the SUT. This requirement

can add a lot of complexity to the tests and causes them to take much, much

longer to run. The latter issue is a major concern with unit tests, which must run

very quickly to ensure that developers will run them frequently.

Root Cause

The code that implements the algorithm we wish to test is highly coupled to the

active object in which it normally executes.

Possible Solution

The key to testing asynchronous code is to separate the logic from the asynchronous

access mechanism. The design-for-testability pattern Humble Object (page 695;

including Humble Dialog and Humble Executable) is a good example of a way

to restructure otherwise asynchronous code so it can be tested in a synchronous

manner.

Cause: Untestable Test Code

Symptoms

The body of a Test Method (page 348) is obscure enough (Obscure Test; see

page 186) or contains enough Conditional Test Logic (page 200) that we wonder

whether the test is correct.

Impact

Any Conditional Test Logic within a Test Method has a higher probability of

producing Buggy Tests (page 260) and will likely result in High Test Mainte-

nance Cost (page 265). Too much code in the test method body can make the

test hard to understand and hard to construct correctly.

Root Cause

The code within the body of the Test Method is inherently hard to test using a

Self-Checking Test (see page 26). To do so, we would have to replace the SUT

with a Test Double that injects the target error and then run the test method

inside another Expected Exception Test (see Test Method) method—much too

much trouble to bother with in all but the most unusual circumstances.

Hard-to-Test Code

Hard-to-Test

Code

212

Chapter 15 Code Smells

Possible Solution

We can remove the need to test the body of a Test Method by making it

extremely simple and relocating any Conditional Test Logic from it into Test

Utility Methods (page 599), for which we can easily write Self-Checking Tests.

Hard-to-Test

Code

213

Test Code Duplication

The same test code is repeated many times.

Many of the tests in a suite need to do similar things. For example, tests often

exercise scenarios that are variations on the same theme. Tests may require simi-

lar ﬁ xture setup or result veriﬁ cation logic. In some cases, even the exercise SUT

phase of many tests involves repeating the same nontrivial logic.

The need for tests to do similar things often results in Test Code Duplication.

Symptoms

Several tests may contain a common subset of essentially the same statements,

as in the following example:

public void testInvoice_addOneLineItem_quantity1_b() {

// Exercise

inv.addItemQuantity(product, QUANTITY);

// Verify

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 1);

// Verify only item

LineItem expItem = new LineItem(inv, product, QUANTITY);

LineItem actual = (LineItem)lineItems.get(0);

assertEquals(expItem.getInv(), actual.getInv());

assertEquals(expItem.getProd(), actual.getProd());

assertEquals(expItem.getQuantity(), actual.getQuantity());

}

public void testRemoveLineItemsForProduct_oneOfTwo() {

// Set up

Invoice inv = createAnonInvoice();

inv.addItemQuantity(product, QUANTITY);

inv.addItemQuantity(anotherProduct, QUANTITY);

LineItem expItem = new LineItem(inv, product, QUANTITY);

// Exercise

inv.removeLineItemForProduct(anotherProduct);

// Verify

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 1);

LineItem actual = (LineItem)lineItems.get(0);

assertEquals(expItem.getInv(), actual.getInv());

assertEquals(expItem.getProd(), actual.getProd());

assertEquals(expItem.getQuantity(), actual.getQuantity());

}

Test Code Duplication

Test Code

Duplication

214

Chapter 15 Code Smells

A single test may also contain repeated groups of similar statements:

public void testInvoice_addTwoLineItems_sameProduct() {

Invoice inv = createAnonInvoice();

LineItem expItem1 = new LineItem(inv, product, QUANTITY1);

LineItem expItem2 = new LineItem(inv, product, QUANTITY2);

// Exercise

inv.addItemQuantity(product, QUANTITY1);

inv.addItemQuantity(product, QUANTITY2);

// Verify

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 2);

// Verify ﬁrst item

LineItem actual = (LineItem)lineItems.get(0);

assertEquals(expItem1.getInv(), actual.getInv());

assertEquals(expItem1.getProd(), actual.getProd());

assertEquals(expItem1.getQuantity(), actual.getQuantity());

// Verify second item

actual = (LineItem)lineItems.get(1);

assertEquals(expItem2.getInv(), actual.getInv());

assertEquals(expItem2.getProd(), actual.getProd());

assertEquals(expItem2.getQuantity(), actual.getQuantity());

}

Both of the preceding examples exhibit Test Code Duplication that is easily noticed.

By comparison, it is more challenging to identify duplication when it occurs across

Test Methods (page 348) that reside in different Testcase Classes (page 373).

Impact

“Cut and paste” often results in many copies of the same code. This code must

be maintained every time the SUT is modiﬁ ed in a way that affects the seman-

tics (e.g., number of arguments, argument attributes, returned object attributes,

calling sequences) of its methods. This necessity can greatly increase the cost

to introduce new functionality (High Test Maintenance Cost; see page 265)

because of the effort involved in updating all tests that contain copies of the

affected code.

Causes

Cause: Cut-and-Paste Code Reuse

“Cut and paste” is a powerful tool for writing code fast but it results in many

copies of the same code, each of which must be maintained in parallel.

Test Code

Duplication

215

Root Cause

Cut-and-Paste Code Reuse is often the default way to reuse logic. Developers

who focus on details of “how” to do something will often repeat the same code

many times because they cannot (or do not take the time to) focus on the big

picture (the intent) of the test.

A contributing factor may be a lack of refactoring skills or refactoring expe-

rience that keeps developers from extracting the big picture from the detailed

code they have written. Of course, time pressure may also be the culprit that

keeps the refactoring from occurring. As a result, test code grows more compli-

cated over time rather than becoming simpler.

Possible Solution

Once Test Code Duplication has occurred, the best solution is to use an Extract

Method [Fowler] refactoring to create a Test Utility Method (page 599) from

one of the examples and then to generalize that method to handle each of the

copies. When the Test Code Duplication consists of ﬁ xture setup logic, we

end up with Creation Methods (page 415) or Finder Methods (see Test Utility

Method). When the logic carries out result veriﬁ cation, we end up with Custom

Assertions (page 474) or Veriﬁ cation Methods (see Custom Assertion).

We can use an Introduce Parameter [JBrains] refactoring to convert any lit-

eral constants inside the extracted method into parameters that can be passed in

to customize the method’s behavior for each test that calls it.

More simply, we can avoid most Test Code Duplication by writing the Test

Methods in an “outside-in” manner, focusing on their intent. Whenever we need

to do something that involves several lines of code, we simply call a nonexis-

tent Test Utility Method to do it. We write all our tests this way and then ﬁ ll in

implementations of the Test Utility Methods to get the tests to compile and run.

(Modern IDEs facilitate this process by providing automatic method skeleton

generation at a click of the mouse.)

Cause: Reinventing the Wheel

While Cut-and-Paste Code Reuse deliberately makes copies of existing code to

reduce the effort of writing tests, it is also possible to accidentally write the same

sequence of statements in different tests.

Root Cause

This problem is primarily caused by a lack of awareness of which Test Utility

Methods are available. It can also be caused by a predisposition to write one’s

own code rather than reuse code written by others.

Test Code Duplication

Test Code

Duplication

216

Chapter 15 Code Smells

Possible Solution

The technical solution is largely the same as for Cut-and-Paste Code Reuse

but the process solution is somewhat different. The test automater must look

around more places to discover which Test Utility Methods are available before

reinventing the wheel (i.e., writing new code).