Meszaros G. xUnit Test Patterns Refactoring Test Code

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

Yikes! That got pretty messy. And we’ll have to do the same thing for every

attribute we want to verify? This is not good. There must be a better way.

Refactoring Notes

Luckily for us, the inventors of xUnit recognized this problem and did the requisite

Extract Method [Fowler] refactoring to create a library of Assertion Methods that

we can call instead. We simply replace the mess of in-line if statements and thrown

exceptions with a call to the appropriate Assertion Method. The next example is

the code for the JUnit assertEquals method. Although the intent of this example

is the same as the code we wrote earlier, it has been rewritten in terms of guard

clauses that identify when things are equal.

/**

* Asserts that two objects are equal. If they are not,

* an AssertionFailedError is thrown with the given message.

static public void assertEquals(String message,

Object expected,

Object actual) {

if (expected == null && actual == null)

return;

if (expected != null && expected.equals(actual))

return;

failNotEquals(message, expected, actual);

}

The method failNotEquals is a Test Utility Method that fails the test and provides

a diagnostic assertion message.

Example: Equality Assertion

Here is the same assertion logic recoded to take advantage of JUnit’s Equality

Assertion:

assertEquals( x, y );

Here is the same assertion coded in C#. Note the classname qualiﬁ er and the

resulting difference in the method name:

Assert.AreEqual( x, y );

Example: Fuzzy Equality Assertion

To compare two ﬂ oating-point numbers (which are rarely ever really equal), we

specify the acceptable differences using a Fuzzy Equality Assertion:

Assertion

Method

368

Chapter 19 xUnit Basics Patterns

assertEquals( 3.1415, diameter/2/radius, 0.001);

assertEquals( expectedXml, actualXml, elementsToCompare );

Example: Stated Outcome Assertion

To insist that a particular outcome has occurred, we use a Stated Outcome

Assertion:

assertNotNull( a );

assertTrue( b > c );

assertNonZero( b );

Example: Expected Exception Assertion

Here is an example of how we verify that the correct exception was raised when

we have blocks. In Smalltalk’s SUnit, it looks like this:

self

should: [Flight new mileage: -1122]

raise: RuntimeError new 'Should have raised error'

The should: indicates the block of code to run (surrounded by square brackets),

while the raise: speciﬁ es the expected exception object. In Ruby, it looks like

this:

assert_raises( RuntimeError,

"Should have raised error")

{ﬂight.setMileage(-1122) }

The Ruby language syntax also lets us use this “control structure”-style syntax

by delimiting the block using do/end instead of curly braces:

assert_raises( RuntimeError, "Should have raised error") do

ﬂight.setMileage(-1122)

end

Example: Single-Outcome Assertion

To fail the test, use the Single Outcome Assertion:

fail( "Expected an exception" );

unﬁnishedTest();

Assertion

Method

Assertion Method

369

Assertion Message

How do we structure our test logic to know which assertion failed?

We include a descriptive string argument in each call to an

Assertion Method.

We make tests Self-Checking (see page 26) by including calls to Assertion Meth-

ods (page 362) that specify the expected outcome. When a test fails, the Test

Runner (page 377) writes an entry to the test result log.

A well-crafted Assertion Message makes it very easy to determine which asser-

tion failed and exactly what the symptoms were when the failure happened.

How It Works

Every Assertion Method takes an optional string parameter that is included in the

failure log. When the condition being asserted is not true, the Assertion Message is

output to the Test Runner’s log along with whatever output the assertion method

normally generates.

When to Use It

There are two schools of thought on this subject. Test drivers who belong to the

“single assertion per Test Method” school believe that they don’t need to include

Assertion Messages because only one assertion can possibly fail and, therefore,

they always know exactly which assertion happened. They count on the Assertion

Method to include the arguments (e.g., expected “x” but was “y”) but they don’t

need to include a message.

Testcase

Object

testMethod_1

Testcase

Object

testMethod_n

Test

Test Failed:

message

Suite

Object

Create

Fixture

SUT

run

Setup

Exercise

Teardown

Assertion

Method

message

Testcase

Class

testMethod_1

testMethod_n

Suite

Test Runner

Verify

Testcase

Object

testMethod_1

Testcase

Object

testMethod_n

Test

Test Failed:

message

Suite

Object

Create

Fixture

SUT

run

Setup

Exercise

Teardown

Assertion

Method

message

Testcase

Class

testMethod_1

testMethod_n

Suite

Test Runner

Verify

Assertion

Message

Chapter 19 xUnit Basics Patterns

370

Conversely, people who ﬁ nd themselves coding several or many assertion

method calls in their tests should strongly consider including a message that at

least distinguishes which assertion failed. This information is especially impor-

tant if the tests are frequently run using a Command-Line Test Runner (see Test

Runner), which rarely provides failure location information.

Implementation Notes

It is easy to state that we need a message for each assertion method call—but

what should we say in the message? It is useful to take a moment as we write

each assertion and ask ourselves what the person reading the failure log would

hope to get out of it.

Variation: Assertion-Identifying Message

When we include several assertions of the same type in the same Test

Method (page 348), we make it more difﬁ cult to determine exactly which one

failed the test. By including some unique text in each Assertion Message, we can

make it very easy to determine which assertion method call failed. A common

practice is to use the name of the variable or attribute being asserted on as the

message. This technique is very simple and requires very little thought. Another

option is to number the assertions. This information would certainly be unique

but understanding it may be less intuitive as we would have to look at the code

to determine which assertion was failing.

Variation: Expectation-Describing Message

When a test fails, we know what has actually happened. The big question is,

“What should have happened?” There are several ways of documenting the

expected behavior for the test reader. For example, we could place comments in

the test code. A better solution is to include a description of the expectation in

the Assertion Message. While this is done automatically for an Equality Asser-

tion (see Assertion Method), we need to provide this information ourselves for

any Stated Outcome Assertions (see Assertion Method).

Variation: Argument-Describing Message

Some types of Assertion Methods provide less helpful failure messages than

others. Among the worst are Stated Outcome Assertions such as assertTrue

(aBooleanExpression)

. When they fail, all we know is that the stated outcome did

not occur. In these cases we can include the expression that was being evalu-

ated (including the actual values) as part of the Assertion Message text. The

Assertion

Message

Assertion Message

371

test maintainer can then examine the failure log and determine what was being

evaluated and why it caused the test to fail.

Motivating Example

assertTrue( a > b );

assertTrue( b > c );

This code emits a failure message—something like “Assertion Failed.” From

this output, we cannot even tell which of the two Assertion Messages failed. Not

very useful, is it?

Refactoring Notes

Fixing this problem is a simple matter of adding one more parameter to each

Assertion Method call. In this case, we want to communicate that we are

expecting “a” to be greater than “b.” Of course, it would also be useful to be

able to see what the values of “a” and “b” actually were. We can add both

pieces of information into the Assertion Message through some judicious string

concatenation.

Example: Expectation-Describing Message

Here is the same test with the Argument-Describing Message added:

assertTrue( "Expected a > b but a was '" + a.toString() +

"' and b was '" + b.toString() + "'",

a.gt(b) );

assertTrue( "Expected b > c but b was '" + b.toString() +

"' and c was '" + c.toString + "'",

b > c );

This will now result in a useful failure message:

Assertion Failed. Expected a > b but a was '17' and b was '19'.

Of course, this output would be even more meaningful if the variables had

Intent-Revealing Names [SBPP]!

Assertion

Message

372

Chapter 19 xUnit Basics Patterns

Testcase Class

Where do we put our test code?

We group a set of related Test Methods on a single Testcase Class.

We put our test logic into Test Methods (page 348) but those Test Methods need

to be associated with a class. A Testcase Class gives us a place to host those

methods that we can later turn into Testcase Objects (page 382).

How It Works

We collect all Test Methods that are related in some way onto a special kind

of class, the Testcase Class. At runtime, the Testcase Class acts as a Test Suite

Factory (see Test Enumeration on page 399) that creates a Testcase Object for

each Test Method. It adds all of these objects to a Test Suite Object (page 387)

that the Test Runner (page 377) will use to run them all.

Why We Do This

In object-oriented languages, we prefer to put our Test Methods onto a class

rather than having them as global functions or procedures (even if that is allowed).

By making them instance methods of a Testcase Class, we can create a Testcase

Object for each test by instantiating the Testcase Class once for each Test Method.

This strategy allows us to manipulate the Test Methods at runtime.

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Testcase

Class

testMethod_1

testMethod_n

Test

Suite

Object

Exercise

Create

Exercise

Create

Fixture

SUT

Run

Suite

Test Runner

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Testcase

Class

testMethod_1

testMethod_n

Test

Suite

Object

Exercise

Create

Exercise

Create

Fixture

SUT

Run

Suite

Test Runner

Testcase

Class

Testcase Class

Also known as:

Test Fixture

373

Class–Instance Duality

Back in high school physics, we learned about the “wave–particle duality”

of light. Sometimes light acts like a particle (e.g., going through a small

aperture), and sometimes it acts like a wave (e.g., rainbows). The behavior

of Testcase Classes (page 373) sometimes reminds me of this concept. Let

me explain why.

Developers new to xUnit often ask, “Why is the class we subclass called

TestCase when we have several Test Methods on it? Shouldn’t it be called

TestSuite?” These questions make a lot of sense when we are focused

primarily on the view of the class when we are writing the test code as

opposed to when we are running the code.

When we are writing test code, we concentrate on the Test Methods. The

Testcase Class is primarily just a place to put the methods. About the only

time we think of objects is when we use Implicit Setup (page 424) and

need to create ﬁ elds (instance variables) to hold them between the invo-

cation of the setUp method and when they are used in the Test Method.

When developers new to xUnit test automation are writing their ﬁ rst tests,

they tend to code by example. Following an existing example is a good

way to get something working quickly but it doesn’t necessarily help the

developer understand what is really going on.

At runtime, the xUnit framework typically creates one instance of the

Testcase Class for each Test Method. The Testcase Class acts as a Test

Suite Factory (see Test Enumeration on page 399) that builds a Test Suite

Object (page 387) containing all the instances of itself, one instance for

each Test Method. Now, it’s not very often that a static method on a class

returns an instance of another class containing many instances of itself.

If this behavior wasn’t odd enough, the fact that xUnit reports the test

failures using the Test Method name can be enough to obscure from many

test automaters the existence of “objects inside.”

When we examine the object relationships at runtime, things become a bit

clearer. The Test Suite Object returned by the Test Suite Factory contains

one or more Testcase Objects (page 382). So far, so good. Each of these

objects is an instance of our Testcase Class. Each instance is conﬁ gured

to run one of the Test Methods. More importantly, each will run a differ-

ent Test Method. (How this happens is described in more detail in Test

Discovery on page 393.) So each instance of our Testcase Class is, indeed,

a test case. The Test Methods are just how we tell each instance what it

should test.

Testcase

Class

Chapter 19 xUnit Basics Patterns

374