Meszaros G. xUnit Test Patterns Refactoring Test Code

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

708

Chapter 26 Design-for-Testability Patterns

ResultsFileName = RpbFiles.ActualResultFileName

ShowFileInBrowser ResultsFileName

End Sub

Private Sub EnsureImplExists()

If Implementation Is Nothing Then

Set Implementation = New OcsScriptViewerImpl

End If

End Sub

Here’s the testable component OcsScriptViewerImpl that the Humble Object calls:

' ResultViewer Implementation:

Public Function getTestResultFileNames(ResultKey As Variant) As OcsRpbFiles

On Error GoTo Error

Dim Attachments As Collection

Dim thisTest As Run

Dim RpbFiles As New OcsRpbFiles

Call EnsureConnectedToTd

Set Attachments = testManager.GetAllAttachmentsOfRunTest(ResultKey)

Call RpbFiles.LoadFromCollection(Attachments, "RunTest")

Set getTestResultFileNames = RpbFiles

Exit Function

Error:

' do something ...

End Function

We could now instantiate this OcsScriptViewerImpl class easily and write VbUnit

tests for it. I’ve omitted the tests for space reasons because they don’t really show

anything particularly interesting.

Example: Humble Transaction Controller

Transaction Rollback Teardown (page 668) contains an example of writing tests

that bypass the Humble Transaction Controller.

Further Reading

See http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

for Michael Feathers’ original write-up of the Humble Dialog pattern.

Humble

Object

709

Test Hook

How do we design the SUT so that we can replace its dependencies at runtime?

We modify the SUT to behave differently during the test.

Almost every piece of code depends on some other classes, objects, modules, or

procedures. To unit-test a piece of code properly, we would like to isolate it from

its dependencies. Such isolation is difﬁ cult to achieve if those dependencies are

hard-coded within the code in the form of literal classnames.

Test Hook is a “method of last resort” for introducing test-speciﬁ c behavior

during automated testing.

How It Works

We modify the behavior of the SUT to support testing by putting a hook directly

into the SUT or into a DOC. This approach implies that we use some kind of

testing ﬂ ag that can be checked in the appropriate place.

When to Use It

Sometimes it is appropriate to use this “pattern of last resort” when we cannot

use either Dependency Injection (page 678) or Dependency Lookup (page 686).

In this situation, we use a Test Hook because we have no other way to address

the Untested Code (see Production Bugs on page 268) caused by a Hard-Coded

Dependency (see Hard-to-Test Code on page 209).

DOC

SUT

Usage

Exercise

Testing?

Production

Logic

Test-

Specific

Logic

Setup

Exercise

Verify

Teardown

Testing?

Yes

Production

Logic

Test-

Specific

Logic

Yes

DOC

SUT

Usage

Exercise

Testing?

Production

Logic

Test-

Specific

Logic

Setup

Exercise

Verify

Teardown

Testing?

Yes

Production

Logic

Test-

Specific

Logic

Yes

Test Hook

710

Chapter 26 Design-for-Testability Patterns

A Test Hook may be the only way to introduce Test Double (page 522)

behavior when we are programming in a procedural language that does not

support objects, function pointers, or any other form of dynamic binding.

Test Hooks can be used as a transition strategy to bring legacy code under

the testing umbrella. We can introduce testability using the Test Hooks and then

use those Tests as Safety Net (see page 24) while we refactor for even more test-

ability. At some point we should be able to discard the initial round of tests that

required the Test Hooks because we have enough “modern” tests to protect us.

Implementation Notes

The essence of the Test Hook pattern is that we insert some code into the SUT

that lets us test it. Regardless of how we insert this code into the SUT, the code

itself can either

• Divert control to a Test Double instead of the real object, or

• Be the Test Double within the real object, or

• Be a test-speciﬁ c Decorator [GOF] that delegates to the real object

when in production.

The ﬂ ag that indicates testing is in progress can be a compile-time constant,

which may, for example, cause the compiler to optimize out all the testing logic.

In languages that support preprocessors or compiler macros, such constructs

may also be used to remove the Test Hook before the code enters the production

phase. The value of the ﬂ ag can also be read in from conﬁ guration data or stored

in a global variable that the test sets directly.

Motivating Example

The following test cannot be made to pass “as is”:

public void testDisplayCurrentTime_AtMidnight() {

// ﬁxture setup

TimeDisplay sut = new TimeDisplay();

// exercise SUT

String result = sut.getCurrentTimeAsHtmlFragment();

// verify direct output

String expectedTimeString =

"<span class=\"tinyBoldText\">Midnight</span>";

assertEquals( expectedTimeString, result);

}

This test almost always fails because it depends on a DOC to return the current

time to the SUT. The test cannot control the values returned by that component,

Test Hook

711

the DefaultTimeProvider. As a consequence, this test will pass only when the system

time is exactly midnight.

public String getCurrentTimeAsHtmlFragment() {

Calendar currentTime;

try {

currentTime = new DefaultTimeProvider().getTime();

} catch (Exception e) {

return e.getMessage();

}

// etc.

}

Because the SUT is hard-coded to use a particular class to retrieve the time, we

cannot replace the DOC with a Test Double. As a result, this test is nondeter-

ministic and pretty much useless. We need to ﬁ nd a way to gain control over the

indirect inputs of the SUT.

Refactoring Notes

We can introduce a Test Hook by creating a ﬂ ag that can be checked into the

SUT. We then wrap the production code with an if/then/else control structure

and put the test-speciﬁ c logic into the then clause.

Example: Test Hook in System Under Test

Here’s the production code modiﬁ ed to accommodate testing via a Test Hook:

public String getCurrentTimeAsHtmlFragment() {

Calendar theTime;

try {

if (TESTING) {

theTime = new GregorianCalendar();

theTime.set(Calendar.HOUR_OF_DAY, 0);

theTime.set(Calendar.MINUTE, 0);}

else {

theTime = new DefaultTimeProvider().getTime();

}

} catch (Exception e) {

return e.getMessage();

}

// etc.

Here we have implemented the testing ﬂ ag as global constant, which we can

edit as necessary. This ﬂ exibility implies a separate build step is necessary for

versions of the system to be tested. Such a strategy is somewhat safer than using

a dynamic conﬁ guration parameter or member variable because many compilers

will optimize this hook right out of the object code.

Test Hook

712

Chapter 26 Design-for-Testability Patterns

Example: Test Hook in Depended-on Component

We can also introduce a Test Hook by putting the hook into a DOC rather than

into the SUT:

public Calendar getTime() throws TimeProviderEx {

Calendar theTime = new GregorianCalendar();

if (TESTING) {

theTime.set(Calendar.HOUR_OF_DAY, 0);

theTime.set(Calendar.MINUTE, 0);}

else {

// just return the calendar

}

return theTime;

};

This approach is somewhat better because we are not modifying the SUT as we

test it.

Test Hook

713

Chapter 27

Value Patterns

Patterns in This Chapter

Literal Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714

Derived Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718

Generated Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723

Dummy Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728

Value

Patterns

714

Chapter 27 Value Patterns

Literal Value

How do we specify the values to be used in tests?

We use literal constants for object attributes and assertions.

BigDecimal expectedTotal = new BigDecimal("99.95");

The values we use for the attributes of objects in our test ﬁ xture and the expect-

ed outcome of our test are often related to one another in a way that is deﬁ ned

in the requirements. Getting these values—and, in particular, the relationship

between the pre-conditions and the post-conditions—right is crucial because it

drives the correct behavior into the SUT.

Literal Values are a popular way to specify the values of attributes of objects

in a test.

How It Works

We use a literal constant of the appropriate type for each attribute of an

object or for use as an argument of a method call to the SUT or an Assertion

Method (page 362). The expected values are calculated by hand, calculator, or

spreadsheet and hard-coded within the test as Literal Values.

When to Use It

Using a Literal Value in-line makes it very clear which value is being used; there

is no doubt about the value’s identity because it is right in front of our face.

Unfortunately, using Literal Values can make it difﬁ cult to see the relationships

between the values used in various places in the test, which may in turn lead to

Obscure Tests (page 186). It certainly makes sense to use Literal Values if the

testing requirements specify which values are to be used and we want to make it

clear that we are, in fact, using those values. [We might sometimes consider us-

ing a Data-Driven Test (page 288) instead to avoid the effort and transcription

errors associated with copying the data into test methods.]

One downside of using a Literal Value is that we might use the same value

for two unrelated attributes; if the SUT happens to use the wrong one, tests

may pass even though they should not. If the Literal Value is a ﬁ lename or a key

used to access a database, the meaning of the value is lost—the content of the

ﬁ le or record actually drives the behavior of the SUT. Using a Literal Value as

the key does nothing to help the reader understand the test in such a case, and

we are likely to suffer from Obscure Tests.

Also known as:

Hard-Coded

Value, Constant

Value

Literal Value

715

If the values in the expected outcome can be derived from the values in the

ﬁ xture setup logic, we will be more likely to use the Tests as Documentation

(see page 23) if we use Derived Values (page 718). Conversely, if the values are

not important to the speciﬁ cation of the logic being tested, we should consider

using Generated Values (page 723).

Implementation Notes

The most common way to use a Literal Value is with literal constants within

the code. When the same value needs to be used in several places in the test

(typically during ﬁ xture setup and result veriﬁ cation), this approach can

obscure the relationship between the test pre-conditions and post-conditions.

Introducing an evocatively named symbolic constant can make this relationship

much clearer. Likewise, if we cannot use a self-describing value, we can still make

the code easier to use by deﬁ ning a suitably named symbolic constant and using

it wherever we would have used the Literal Value.

Variation: Symbolic Constant

When we need to use the same Literal Value in several places in a single Test

Method (page 348) or within several distinct tests, it is a good practice to use a

Symbolic Constant instead of a Literal Value. A Symbolic Constant is function-

ally equivalent to a Literal Value but reduces the likelihood of High Test Mainte-

nance Cost (page 265).

Variation: Self-Describing Value

When several attributes of an object need the same kind of value, using different

values provides advantages by helping us to prove that the SUT is working with

the correct attribute. When an attribute or argument is an unconstrained string,

it can be useful to choose a value that describes the role of the value in the test

(a Self-Describing Value). For example, using “Not an existing customer” for

the name of a customer might be more helpful to the reader than using “Joe

Blow,” especially when we are debugging or when the attributes are included in

the test failure output.

Example: Literal Value

Because Literal Value is usually the starting point when writing tests, I’ll dis-

pense with a motivating example and cut straight to the chase. Here’s an

example of the Literal Value pattern in action. Note the use of Literal Values

in both the ﬁ xture setup logic and the assertion.

Literal Value

716

Chapter 27 Value Patterns

public void testAddItemQuantity_1() throws Exception {

Product product = new Product("Widget", 19.95);

Invoice invoice = new Invoice();

// Exercise

invoice.addItemQuantity(product, 1);

// Verify

List lineItems = invoice.getLineItems();

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

assertEquals(new BigDecimal("19.95"),

actualItem.getExtendedPrice());

}

The Product constructor requires both a name and a cost. The assertion on the

extendedCost of the lineItem requires a value for the total cost of the product for

that line item. In this example, we included these values as hard-coded literal

constants. In the next example, we’ll use symbolic constants instead.

Refactoring Notes

We can reduce the Test Code Duplication (page 213) in the form of the hard-

coded Literal Value of 19.95 by doing a Replace Magic Number with Symbolic

Constant [Fowler] refactoring.

Example: Symbolic Constant

This refactored version of the original test replaces the duplicated Literal Value

of the widget’s price (19.95) with a suitably named Symbolic Constant that is

used during ﬁ xture setup as well as result veriﬁ cation:

public void testAddItemQuantity_1s() throws Exception {

BigDecimal widgetPrice = new BigDecimal("19.95");

Product product = new Product("Widget", widgetPrice);

Invoice invoice = new Invoice();

// Exercise

invoice.addItemQuantity(product, 1);

// Verify

List lineItems = invoice.getLineItems();

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

assertEquals(widgetPrice, actualItem.getExtendedPrice());

}

Literal Value

717

Example: Self-Describing Value

This refactored version of the test provides a Self-Describing Value for the

mandatory name argument passed to the Product constructor. This value is

not used by the method we are testing; it is merely stored for later access by

another method we are not testing here.

public void testAddItemQuantity_1b() throws Exception {

BigDecimal widgetPrice = new BigDecimal("19.95");

Product product = new Product("Irrelevant product name",

widgetPrice);

Invoice invoice = new Invoice();

// Exercise

invoice.addItemQuantity(product, 1);

// Verify

List lineItems = invoice.getLineItems();

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

assertEquals(widgetPrice, actualItem.getExtendedPrice());

}

Example: Distinct Value

This test needs to verify that the item’s name is taken from the product’s name.

We’ll use a Distinct Value for the name and the SKU so we can tell them apart.

public void testAddItemQuantity_1c() throws Exception {

BigDecimal widgetPrice = new BigDecimal("19.95");

String name = "Product name";

String sku = "Product SKU";

Product product = new Product(name, sku, widgetPrice);

Invoice invoice = new Invoice();

// Exercise

invoice.addItemQuantity(product, 1);

// Verify

List lineItems = invoice.getLineItems();

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

assertEquals(name, actualItem.getName());

}

This also happens to be an example of a self-describing value.

Literal Value