Meszaros G. xUnit Test Patterns Refactoring Test Code

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

718

Derived Value

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

We use expressions to calculate values that can be derived from

other values.

BigDecimal expectedTotal = itemPrice.multiply(QUANTITY);

The values we use for the attributes of objects in our test ﬁ xtures and the result

veriﬁ cation parts of our tests are often related to one another in a way that is

deﬁ ned in the requirements. Getting these values—and, in particular, the rela-

tionship between the pre-conditions and the post-conditions—right is crucial

because it drives the correct behavior into the SUT and helps the tests act as

documentation of our software.

Often, some of these values can be derived from other values in the same test.

In these cases the beneﬁ ts from using our Tests as Documentation (see page 23)

are improved if we show the derivation by calculating the values using the appro-

priate expression.

How It Works

Computers are really good at math and string concatenation. We can avoid

doing the math in our head (or with a calculator) by coding the math for

expected results as arguments of the Assertion Method (page 362) calls directly

into the tests. We can also use Derived Values as arguments for ﬁ xture object

creation and as method arguments when exercising the SUT.

Derived Values, by their very nature, encourage us to use variables or symbolic

constants to hold the values. These variables/constants can be initialized at com-

pile time (constants), during class or Testcase Object (page 382) initialization,

during ﬁ xture setup, or within the body of the Test Method (page 348).

When to Use It

We should use a Derived Value whenever we have values that can be derived in

some deterministic way from other values in our tests. The main drawback of using

Derived Values is that the same math error (e.g., rounding errors) could appear in

both the SUT and the tests. To be safe, we might want to code a few of the patho-

logical test cases using Literal Values (page 714) just in case such a problem might

be present. If the values we are using must be unique or don’t affect the logic in the

SUT, we may be better off using Generated Values (page 723) instead.

Also known as:

Calculated

Value

Derived

Value

Chapter 27 Value Patterns

719

We can use a Derived Value either as part of ﬁ xture setup (Derived Input

or One Bad Attribute) or when determining the expected values to be com-

pared with those generated by the SUT (Derived Expectation). These uses are

described in a bit more detail later in this section.

Variation: Derived Input

Sometimes our test ﬁ xture contains similar values that the SUT might compare

or use to base its logic on the difference between them. For example, a Derived

Input might be calculated in the ﬁ xture setup portion of the test by adding the

difference to a base value. This operation makes the relationship between the

two values explicit. We can even put the value to be added in a symbolic constant

with an Intent-Revealing Name [SBPP] such as MAXIMUM_ALLOWABLE_TIME_DIFFERENCE.

Variation: One Bad Attribute

A Derived Input is often employed when we need to test a method that takes a

complex object as an argument. For example, thorough “input validation” testing

requires that we exercise the method with each of the attributes of the object set to

one or more possible invalid values to ensure that it handles all of these cases cor-

rectly. Because the ﬁ rst rejected value could cause termination of the method, we

must verify each bad attribute in a separate call to the SUT; each of these calls, in

turn, should be done in a separate test method (each should be a Single-Condition

Test; see page 45). We can instantiate the invalid object easily by ﬁ rst creating a

valid object and then replacing one of its attributes with an invalid value. It is best

to create the valid object using a Creation Method (page 415) so as to avoid Test

Code Duplication (page 213).

Variation: Derived Expectation

When some value produced by the SUT should be related to one or more of the

values we passed in to the SUT as arguments or as values in the ﬁ xture, we can

often derive the expected value from the input values as the test executes rather

than using precalculated Literal Values. We then use the result as the expected

value in an Equality Assertion (see Assertion Method).

Motivating Example

The following test doesn’t use Derived Values. Note the use of Literal Values in

both the ﬁ xture setup logic and the assertion.

public void testAddItemQuantity_2a() throws Exception {

BigDecimal widgetPrice = new BigDecimal("19.99");

Derived Value

Derived

Value

720

Chapter 27 Value Patterns

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

Invoice invoice = new Invoice();

// Exercise

invoice.addItemQuantity(product, 5);

// Verify

List lineItems = invoice.getLineItems();

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

assertEquals(new BigDecimal("99.95"),

actualItem.getExtendedPrice());

}

Test readers may have to do some math in their heads to fully appreciate the

relationship between the values in the ﬁ xture setup and the value in the result

veriﬁ cation part of the test.

Refactoring Notes

To make this test more readable, we can replace any Literal Values that are actu-

ally derived from other values with formulas that calculate these values.

Example: Derived Expectation

The original example contained only one line item for ﬁ ve instances of the prod-

uct. We therefore calculated the expected value of the extended price attribute by

multiplying the unit price by the quantity, which makes the relationship between

the values explicit.

public void testAddItemQuantity_2b() throws Exception {

BigDecimal widgetPrice = new BigDecimal("19.99");

BigDecimal numberOfUnits = new BigDecimal("5");

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

Invoice invoice = new Invoice();

// Exercise

invoice.addItemQuantity(product, numberOfUnits);

// Verify

List lineItems = invoice.getLineItems();

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

BigDecimal totalPrice = widgetPrice.multiply(numberOfUnits);

assertEquals(totalPrice, actualItem.getExtendedPrice());

}

Note that we have also introduced symbolic constants for the unit price and

quantity to make the expression even more obvious and to reduce the effort of

changing the values later.

Derived

Value

721

Example: One Bad Attribute

Suppose we have the following Customer Factory Method [GOF], which takes

a CustomerDto object as an argument. We want to write tests to verify what occurs

when we pass in invalid values for each of the attributes in the CustomerDto. We

could create the CustomerDto in-line in each Test Method with the appropriate

attribute initialized to some invalid value.

public void testCreateCustomerFromDto_BadCredit() {

// ﬁxture setup

CustomerDto customerDto = new CustomerDto();

customerDto.ﬁrstName = "xxx";

customerDto.lastName = "yyy";

// etc.

customerDto.address = createValidAddress();

customerDto.creditRating = CreditRating.JUNK;

// exercise the SUT

try {

sut.createCustomerFromDto(customerDto);

fail("Expected an exception");

} catch (InvalidInputException e) {

assertEquals( "Field", "Credit", e.ﬁeld );

}

public void testCreateCustomerFromDto_NullAddress() {

// ﬁxture setup

CustomerDto customerDto = new CustomerDto();

customerDto.ﬁrstName = "xxx";

customerDto.lastName = "yyy";

// etc.

customerDto.address = null;

customerDto.creditRating = CreditRating.AAA;

// exercise the SUT

try {

sut.createCustomerFromDto(customerDto);

fail("Expected an exception");

} catch (InvalidInputException e) {

assertEquals( "Field", "Address", e.ﬁeld );

}

The obvious problem with this code is that we end up with a lot of Test Code

Duplication because we need at least one test per attribute. The problem

becomes even worse if we are doing incremental development: We will require

more tests for each newly added attribute, and we will have to revisit all existing

tests to add the new attribute to the Factory Method signature.

Derived Value

Derived

Value

722

Chapter 27 Value Patterns

The solution is to deﬁ ne a Creation Method that produces a valid instance of

the CustomerDto (by doing an Extract Method [Fowler] refactoring on one of the

tests) and uses it in each test to create a valid DTO. Then we simply replace one

of the attributes with an invalid value in each of the tests. Each test now has an

object with One Bad Attribute, with each one invalid in a slightly different way.

public void testCreateCustomerFromDto_BadCredit_OBA() {

CustomerDto customerDto = createValidCustomerDto();

customerDto.creditRating = CreditRating.JUNK;

try {

sut.createCustomerFromDto(customerDto);

fail("Expected an exception");

} catch (InvalidInputException e) {

assertEquals( "Field", "Credit", e.ﬁeld );

}

public void testCreateCustomerFromDto_NullAddress_OBA() {

CustomerDto customerDto = createValidCustomerDto();

customerDto.address = null;

try {

sut.createCustomerFromDto(customerDto);

fail("Expected an exception");

} catch (InvalidInputException e) {

assertEquals( "Field", "Address", e.ﬁeld );

}

Derived

Value

723

Generated Value

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

We generate a suitable value each time the test is run.

BigDecimal uniqueCustomerNumber = getUniqueNumber();

When initializing the objects in the test ﬁ xture, one issue that must be dealt

with is the fact that most objects have various attributes (ﬁ elds) that need to be

supplied as arguments to the constructor. Sometimes the exact values to be used

affect the outcome of the test. More often than not, however, it is important

only that each object use a different value. When the precise values of these

attributes are not important to the test, it is important not to have them visible

within the test!

Generated Values are used in conjunction with Creation Methods (page 415)

to help us remove this potentially distracting information from the test.

How It Works

Instead of deciding which values to use in our tests while we are coding the tests,

we generate the values when we actually execute the tests. We can then pick values

to satisfy speciﬁ c criteria such as “must be unique in the database” that can be

determined only as the test run unfolds.

When to Use It

We use a Generated Value whenever we cannot or do not want to specify the test

values until the test is executing. Perhaps the value of an attribute is not expected

to affect the outcome of the test and we don’t want to be bothered to deﬁ ne Literal

Values (page 714), or perhaps we need to ensure some quality of the attribute that

can be determined only at runtime. In some cases, the SUT requires the value of an

attribute to be unique; using a Generated Value can ensure that this criterion is

satisﬁ ed and thereby prevent Unrepeatable Tests (see Erratic Test on page 228) and

Test Run Wars (see Erratic Test) by reducing the likelihood of a test conﬂ icting with

its parallel incarnation in another test run. Optionally, we can use this distinct value

for all attributes of the object; object recognition then becomes very easy when we

inspect the object in a debugger.

One thing to be wary of is that different values could expose different

bugs. For example, a single-digit number may be formatted correctly, whereas

a multidigit number might not (or vice versa). Generated Values can result

Generated Value

Generated

Value

724

Chapter 27 Value Patterns

in Nondeterministic Tests (see Erratic Test); if we encounter nondeterminism

(sometimes the test passes and then fails during the very next run), we must

check the SUT code to see whether differences in value could be the root cause.

In general, we shouldn’t use a Generated Value unless the value must be

unique because of the nondeterminism such a value may introduce. The obvi-

ous alternative is to use a Literal Value. A less obvious alternative is to use a

Derived Value (page 718), especially when we must determine the expected

results of a test.

Implementation Notes

We can generate values in a number of ways. The appropriateness of each tech-

nique depends on the circumstance.

Variation: Distinct Generated Value

When we need to ensure that each test or object uses a different value, we can take

advantage of Distinct Generated Values. In such a case, we can create a set of util-

ity functions that will return unique values of various types (e.g., integers, strings,

ﬂ oating-point numbers). The various getUnique methods can all be built upon an

integer sequence number generator. For numbers that must be unique within the

scope of a shared database, we can use database sequences or a sequence table.

For numbers that must be unique within the scope of a particular test run, we can

use an in-memory sequence number generator (e.g., use a Java static variable that

is incremented before usage). In-memory sequence numbers that start from the

number 1 each time a test suite is run offer a useful quality: The values generated

in each test are the same for each run and can simplify debugging.

Variation: Random Generated Value

One way to obtain good test coverage without spending a lot of time analyzing

the behavior and generating test conditions is to use different values each time

we run the tests. Using a Random Generated Value is one way to accomplish

this goal. While use of such values may seem like a good idea, it makes the tests

nondeterministic (Nondeterministic Tests) and can make debugging failed tests

very difﬁ cult. Ideally, when a test fails, we want to be able to repeat that test

failure on demand. To do so, we can log the Random Generated Value as the test

is run and show it as part of the test failure. We then need to ﬁ nd a way to force

the test to use that value again while we are troubleshooting the failed test. In

most cases, the effort required outweighs the potential beneﬁ t. Of course, when

we need this technique, we really need it.

Generated

Value

725

Variation: Related Generated Value

An optional enhancement is to combine a Generated Value with a Derived Value

by using the same generated integer as the root for all attributes of a single object.

This result can be accomplished by calling getUniqueInt once and then using that

value to build unique strings, ﬂ oating-point numbers, and other values. With a

Related Generated Value, all ﬁ elds of the object contain “related” data, which

makes the object easier to recognize when debugging. Another option is to sepa-

rate the generation of the root from the generation of the values by calling gener-

ateNewUniqueRoot

explicitly before calling getUniqueInt, getUniqueString, and so on.

Another nice touch for strings is to pass a role-describing argument to the

function that is combined with the unique integer key to make the code more

intent-revealing. Although we could also pass such arguments to the other

functions, of course we wouldn’t be able to build them into an integer value.

Motivating Example

The following test uses Literal Values for the arguments to a constructor:

public void testProductPrice_HCV() {

// Setup

Product product =

new Product( 88, // ID

"Widget", // Name

new BigDecimal("19.99")); // Price

// Exercise

// ...

}

Refactoring Notes

We can convert the test to use Distinct Generated Values by replacing the Literal

Values with calls to the appropriate getUnique method. These methods simply

increment a counter each time they are called and use that counter value as the

root for construction of an appropriately typed value.

Example: Distinct Generated Value

Here is the same test using a Distinct Generated Value. For the getUniqueString

method, we’ll pass a string describing the role (“Widget Name”).

public void testProductPrice_DVG() {

// Setup

Product product =

Generated Value

Generated

Value

726

Chapter 27 Value Patterns

new Product( getUniqueInt(), // ID

getUniqueString("Widget"), // Name

getUniqueBigDecimal()); // Price

// Exercise

// ...

}

static int counter = 0;

int getUniqueInt() {

counter++;

return counter;

}

BigDecimal getUniqueBigDecimal() {

return new BigDecimal(getUniqueInt());

}

String getUniqueString(String baseName) {

return baseName.concat(String.valueOf( getUniqueInt()));

}

This test uses a different generated value for each argument of the constructor

call. The numbers generated in this way are consecutive but the test reader still

needs to look at a speciﬁ c attribute when debugging to get a consistent view. We

probably should not generate the price value if the logic we were testing was

related to price calculation because that would force our veriﬁ cation logic to

accommodate different total costs.

Example: Related Generated Value

We can ensure that all values used by the test are obviously related by separating

the generation of the root value from the construction of the individual values.

In the following example, we’ve moved the generation of the root to the setUp

method so each test method gets a new value only once. The methods that

retrieve the various values (e.g., getUniqueString) simply use the previously gener-

ated root when deriving the Generated Values.

public void testProductPrice_DRVG() {

// Setup

Product product =

new Product( getUniqueInt(), // ID

getUniqueString("Widget"), // Name

getUniqueBigDecimal()); // Price

// Exercise

// ...

}

Generated

Value

727

static int counter = 0;

public void setUp() {

counter++;

}

int getUniqueInt() {

return counter;

}

String getUniqueString(String baseName) {

return baseName.concat(String.valueOf( getUniqueInt()));

}

BigDecimal getUniqueBigDecimal() {

return new BigDecimal(getUniqueInt());

}

If we looked at this object in an object inspector or database or if we dumped

part of it to a log, we could readily tell which object we were looking at regard-

less of which ﬁ eld we happened to see.

Generated Value

Generated

Value