Meszaros G. xUnit Test Patterns Refactoring Test Code

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

728

Chapter 27 Value Patterns

Dummy Object

How do we specify the values to be used in tests when the only usage is as

irrelevant arguments of SUT method calls?

We pass an object that has no implementation as an argument of a method

called on the SUT.

Invoice inv = new Invoice( new DummyCustomer() );

Getting the SUT into the right state to start a test often requires calling other

methods of the SUT. These methods commonly take as arguments objects that

are stored in instance variables for later use. Often, these objects (or at least

some attributes of these objects) are never used in the code that we are actu-

ally testing. Instead, we create them solely to conform to the signature of some

method we must call to get the SUT into the right state. Constructing these

objects can be nontrivial and adds unnecessary complexity to the test.

In these cases, a Dummy Object

can be passed as an argument, eliminating

the need to build a real object.

How It Works

We create an instance of some object that can be instantiated easily and with

no dependencies; we then pass that instance as the argument of the method of

the SUT. Because it won’t actually be used within the SUT, we don’t need any

implementation for this object. If any of the methods of the Dummy Object are

invoked, the test really should throw an error. Trying to invoke a nonexistent

method will typically produce that result.

When to Use It

We can use Dummy Objects whenever we need to use objects as attributes of

other objects or arguments of methods on the SUT or other ﬁ xture objects. Using

Dummy Objects helps us avoid Obscure Tests (page 186) by leaving out the

irrelevant code that would be necessary to build real objects and by making it

clear which objects and values are not used by the SUT.

If we need to control the indirect inputs or verify the indirect outputs of

the SUT, we should probably use a Test Stub (page 529) or a Mock Object

(page 544) instead. If the object will be used by the SUT but we cannot provide

the real object, we should consider providing a Fake Object (page 551) that

provides just enough behavior for the test to execute.

Also known as:

Dummy,

Dummy

Parameter,

Dummy Value,

Placeholder,

Stub

Dummy

Object

729

We can use one of the value patterns when the SUT really does need to

use the object in some way. Either a Literal Value (page 714), a Generated

Value (page 723), or a Derived Value (page 718) may be appropriate, depend-

ing on the circumstance.

Variation: Dummy Argument

We can use a Dummy Argument whenever methods of the SUT take objects as

arguments

and those objects are not relevant to the test.

Variation: Dummy Attribute

We can use a Dummy Attribute whenever we are creating objects that will be

used as part of the ﬁ xture or as arguments of SUT methods, and some of the

attributes of those objects are not relevant to the test.

Implementation Notes

The simplest implementation of a Dummy Object is to pass a null value as the

argument. This approach works even in a statically typed language such as Java,

albeit only if the method being called doesn’t check for null arguments. If the

method complains when we pass it null, we’ll need to employ a slightly more

sophisticated implementation. The biggest disadvantage to using null is that it is

not very descriptive.

In dynamically typed languages such as Ruby, Perl, and Python, the actual

type of the object will never be checked (because it will never be used), so we

can use any class such as String or Object. In such a case, it is useful to give the

object a Self-Describing Value (see Literal Value) such as “Dummy Customer.”

In statically typed languages (such as Java, C#, and C++), we must ensure that

the Dummy Object is type compatible with the parameter it is to match. Type

compatibility is much easier to achieve if the parameter has an abstract type

(e.g., an Interface in Java) because we can create our own trivial implementation

of the type or pass a suitable Pseudo-Object (see Hard-Coded Test Double on

page 568). If the parameter type is a concrete class, we may be able to create

From Wikipedia: Parameters are also commonly referred to as arguments, although ar-

guments are more properly thought of as the actual values or references assigned to the

parameter variables when the subroutine is called at runtime. When discussing code that

is calling into a subroutine, any values or references passed into the subroutine are the

arguments, and the place in the code where these values or references are given is the

parameter list. When discussing the code inside the subroutine deﬁ nition, the variables in

the subroutine’s parameter list are the parameters, while the values of the parameters at

runtime are the arguments.

Dummy Object

Dummy

Object

730

Chapter 27 Value Patterns

a trivial instance of it or we may need to create an instance of a Test-Speciﬁ c

Subclass (page 579) within our test.

Some Mock Object frameworks have Test Utility Methods (page 599) that

will generate a Dummy Object for a speciﬁ ed class that takes a String argument

for a Self-Describing Value.

While the Dummy Object may, in fact, be null, it is not the same as a Null

Object [PLOPD3]. A Dummy Object is not used by the SUT, so its behavior is

either irrelevant or it should throw an exception when executed. In contrast, a

Null Object is used by the SUT but is designed to do nothing. That’s a small but

very important distinction!

Motivating Example

In this example, we are testing the Invoice but we require a Customer to instantiate

the invoice. The Customer requires an Address, which in turn requires a City. Thus

we ﬁ nd ourselves creating several additional objects just to set up the ﬁ xture. But

if we know that the behavior we are testing should not access the Customer at all,

why do we need to create it and all the objects on which it depends?

public void testInvoice_addLineItem_noECS() {

ﬁnal int QUANTITY = 1;

Product product = new Product(getUniqueNumberAsString(),

getUniqueNumber());

State state = new State("West Dakota", "WD");

City city = new City("Centreville", state);

Address address = new Address("123 Blake St.", city, "12345");

Customer customer= new Customer(getUniqueNumberAsString(),

getUniqueNumberAsString(),

address);

Invoice inv = new Invoice(customer);

// Exercise

inv.addItemQuantity(product, QUANTITY);

// Verify

List lineItems = inv.getLineItems();

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

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

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

assertLineItemsEqual("",expItem, actual);

}

This test is quite cluttered as a result of the extra object creation. How is the

behavior we are testing related to the Address and City? From this test, we can

only assume that there is some relation. But this misleads the test reader!

Dummy

Object

731

Refactoring Notes

If the objects in the ﬁ xture are not relevant to the test, they should not be visible in

the test. Therefore, we should try to eliminate the need to create all these objects.

We could try passing in null for the Customer. In this case, the constructor checks for

null and rejects it, so we have to ﬁ nd another way.

The solution is to replace the object that is not important to our test with a

Dummy Object. In dynamically typed languages, we could just pass in a string.

In statically typed languages such as Java and C#, however, we must pass in a

type-compatible object. In this case, we have chosen to do an Extract Interface

[Fowler] refactoring on Customer to create a new interface and then create a new

implementation class called DummyCustomer. Of course, as part of the Extract Inter-

face refactoring, we must replace all references to Customer with the new interface

name so that the DummyCustomer will be acceptable. A less intrusive option would

be to use a Test-Speciﬁ c Subclass of Customer that adds a test-friendly constructor.

Example: Dummy Values and Dummy Objects

Here’s the same test using a Dummy Object instead of the Product name and the

Customer. Note how much simpler the ﬁ xture setup has become!

public void testInvoice_addLineItem_DO() {

ﬁnal int QUANTITY = 1;

Product product = new Product("Dummy Product Name",

getUniqueNumber());

Invoice inv = new Invoice( new DummyCustomer() );

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

// Exercise

inv.addItemQuantity(product, QUANTITY);

// Verify

List lineItems = inv.getLineItems();

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

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

assertLineItemsEqual("", expItem, actual);

}

Using a Dummy Object for the name of the Product was simple because it is a

string and has no uniqueness requirement. Thus we were able to use a Self-

Describing Value. We were not able to use a Dummy Object for the Product

number because it must be unique, so we left it as a Generated Value. The

Customer was a bit trickier because the LineItem’s constructor expected a non-

null object. Because this example is written in Java, the method parameter is

strongly typed; for this reason, we needed to create an alternative implemen-

tation of the ICustomer interface with a no-argument constructor to simplify

in-line construction. Because the DummyCustomer is never used, we have created

Dummy Object

Dummy

Object

732

Chapter 27 Value Patterns

it in-line rather than declaring a variable to hold it. This choice reduces the

ﬁ xture setup code by one line, and the presence of the in-line constructor call

within the call to the Invoice constructor reinforces the message that we need

the Dummy Object only for the constructor call and not for the rest of the test.

Here is the code for the DummyCustomer:

public class DummyCustomer implements ICustomer {

public DummyCustomer() {

// Real simple; nothing to initialize!

}

public int getZone() {

throw new RuntimeException("This should never be called!");

}

We have implemented the DummyCustomer class with just those methods declared in

the interface; because each method throws an exception, we know when it is hit.

We could also have used a Pseudo-Object for the DummyCustomer. In other circum-

stances we might have been able to simply pass in null or construct a dummy

instance of the real class. The major problem with the latter technique is that we

won’t know for sure if the Dummy Object is actually used.

Further Reading

This refactoring is similar to an Extract Interface [Fowler] refactoring and

an Extract Implementer [Fowler] refactoring, except that Extract Testable

Component does not require keeping the same interface. It can also be

viewed as a special case of the Extract Class [Fowler] refactoring.

In-line Resource

Tests that depend on an unseen external resource create

a Mystery Guest problem.

Move the contents of an external resource into the ﬁ xture

setup logic of the test.

From [RTC]:

To remove the dependency between a test method and some external

resource, we incorporate that resource in the test code. This is done by

setting up a ﬁ xture in the test code that holds the same contents as the

resource. This ﬁ xture is then used instead of the resource to run the test.

A simple example of this refactoring is putting the contents of a ﬁ le that

is used into some string in the test code.

If the contents of the resource are large, chances are high that you are

also suffering from Eager Tests (see Assertion Roulette on page 224).

Consider applying an Extract Method [Fowler] refactoring or a Minimize

Data (page 738) refactoring.

In-line

Resource

Appendix A Test Refactorings

Implementation Notes

The problem with tests that depend on an external resource is that we cannot see

the pre-conditions of the test. The resource may be a ﬁ le sitting in the ﬁ le system,

the contents of a database, or some other object created outside the test. None of

these Prebuilt Fixtures (page 429) is visible to the test reader. The solution is to

make them visible by including the resource in-line within the test. The simplest

way to do so is to create the resource from within the test itself. For example,

we could build the contents of a text ﬁ le by writing to the ﬁ le rather than just

referring to a preexisting ﬁ le. If we delete the ﬁ le at the end of the test, this step

also moves us from a Prebuilt Fixture approach to a Persistent Fresh Fixture

(see Fresh Fixture on page 311) approach. As a result, our tests may execute

somewhat more slowly.

A more innovative way to in-line the external resource is to replace the

actual resource with a Test Stub (page 529) that is initialized within the test. The

contents of the resource then become visible to the test reader. When the system

under test (SUT) executes, it uses the Test Stub instead of the real resource.

Another option is to refactor the design of the SUT so as to improve its test-

ability. We can apply the Extract Testable Component (page 735) refactoring

to the part of the SUT that uses the contents of the resource so that it can be

tested directly without actually accessing an external resource. That is, the test

passes the contents of the resource to the logic that uses it. We can also test the

Humble Object (page 695) that reads the resource independently by replacing

the extracted component with a Test Stub or Mock Object (page 544).

Make Resource Unique

Several tests are accidentally creating or using the same

resource in a Shared Fixture.

Make the name of any resources used by a test unique.

From [RTC]:

A lot of problems originate from the use of overlapping resource names,

either between different tests run by the same user or between simultaneous

test runs done by different users.

Such problems can easily be prevented (or repaired) by using unique

identiﬁ ers for all resources that are allocated—for example, by including

a time stamp. When you also include the name of the test responsible for

Make

Resource

Unique

737

Make Resource Unique