Meszaros G. xUnit Test Patterns Refactoring Test Code

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

regularly during a project. Agile projects tend to do retrospectives after at least

every release (called a release retrospective) and often after every iteration

(called an iteration retrospective.)

root cause analysis

A process wherein the cause of a failure or bug is traced back to all possible

contributing factors. A root cause analysis helps us avoid treating symptoms by

identifying the true sources of our problems. A number of techniques for doing

root cause analysis exist, including Toyota’s “ﬁ ve why’s” [TPS].

round-trip test

A test that interacts only via the “front door” (public interface) of the system

under test (SUT). Compare with layer-crossing test.

service object

An object that provides a service to other objects. Service objects typically do

not have a life cycle of their own; any state they do contain tends to be an aggre-

gate of the states of the entity objects that they vend. The interface of a service

object is often deﬁ ned via a Service Facade [CJ2EEP] class. EJB Session Beans

are one example of a service object.

setter

A method provided by an object speciﬁ cally to set the value of one of its attri-

butes. By convention, it either has the same name as the attribute or its name

includes the preﬁ x “set” (e.g., setName).

smell

A symptom of a problem. A smell doesn’t necessarily tell us what is wrong, be-

cause it may have several possible causes. A smell must pass the “sniffability

test”—that is, it must grab us by the nose and say, “Something is wrong here.” To

ﬁ gure out exactly what the smell means, we must perform root cause analysis.

We classify smells based on where we ﬁ nd them. The most common kinds

are (production) code smells, test smells, and project smells. Test smells may be

either (test) code smells or behavior smells.

Also known as:

service

component

808

Glossary

spike

In agile methods such as eXtreme Programming, a time-boxed experiment used

to obtain enough information to estimate the effort required to implement a new

kind of functionality.

stateless

An object that does not maintain any state between invocations of its opera-

tions. That is, each request is self-contained and does not require that the same

server object be used for a series of requests.

static binding

Resolving exactly which piece of software we will transfer control to at compile

time. Static binding is the opposite of dynamic binding.

static method

In Java, a method that the compiler resolves at compile time (rather than at run-

time using dynamic binding). This behavior is the opposite of dynamic (or virtual

in C++). A static method is also a class method because only class methods can

be resolved at compile time in Java. A static method is not necessarily a class

method in all languages, however. For example:

Assert.assertEquals(message, expected, actual);

static variable

In Java, a variable (ﬁ eld) that the compiler resolves at compile time rather than

at runtime using dynamic binding. A static variable is also a class variable be-

cause only class variables can be resolved at compile time in Java. Being static

(i.e., not dynamic) does not necessarily imply that something is associated with

a class (rather than an instance) in all languages.

STDD

See storytest-driven development.

story

See user story.

Glossary

809

storytest

A customer test that is the “conﬁ rmation” part of the user story “trilogy”: card,

conversation, conﬁ rmation [XPC]. When the storytests are written before any

software is developed, we call the process storytest-driven development.

storytest-driven development (STDD)

A variation of the test-driven development process that entails writing (and

usually automating) customer tests before the development of the correspond-

ing functionality begins. This approach ensures that integration of the various

software units veriﬁ ed by the unit tests results in a usable whole. The term

“storytest-driven development” was ﬁ rst coined by Joshua Kerievsky as part of

his methodology “Industrial XP” [IXP].

STTCPW

“The simplest thing that could possibly work.” This approach is commonly

used on XP projects when someone is over-engineering the software by trying to

anticipate future requirements.

substitutable dependency

A software component may depend on any number of other components. If we are

to test this component by itself, we must be able to replace the other components

with Test Doubles—that is, each component must be a substitutable dependency.

We can turn something into a substitutable dependency in several ways, including

Dependency Injection, Dependency Lookup, and Test-Speciﬁ c Subclass.

synchronous test

A test that interacts with the system under test (SUT) using normal (synchronous)

method calls that return the results that the test will make assertions against. A

synchronous test does not need to coordinate its steps with those of the SUT; this

activity is managed automatically by the runtime system. Contrast this with an

asynchronous test, which runs in a separate thread of control from the SUT.

system under test (SUT)

Whatever thing we are testing. The SUT is always deﬁ ned from the perspective of

the test. When we are writing unit tests, the SUT is whatever class (also known

Also known as:

AUT, CUT,

MUT, OUT

Glossary

810

as CUT), object (also known as OUT), or method (also known as MUT) we are

testing; when we are writing customer tests, the SUT is probably the entire appli-

cation (also known as AUT) or at least a major subsystem of it. The parts of the

application that we are not verifying in this particular test may still be involved

as a depended-on component (DOC).

task

The unit of work assignment (or volunteering) in eXtreme Programming. One

or more tasks may be involved in delivering a user story (a feature).

TDD

See test-driven development.

test

A procedure, whether manually executed or automated, that can be used to

verify that the system under test (SUT) is behaving as expected. Often called a

test case.

test automater

The person or project role that is responsible for building the tests. Sometimes

a “subject matter expert” may be responsible for coming up with the tests to be

automated by the test automater.

test case

Usually a synonym for “test.” In xUnit, it may also refer to a Testcase Class,

which is actually a Test Suite Factory as well as a place to put a set of related

Test Methods.

test code

Code written speciﬁ cally to test other code (either production or other test code).

test condition

A particular behavior of the system under test (SUT) that we need to verify. It

can be described as the following collection of points:

Glossary

811

• If the SUT is in some state S1, and

• We exercise the SUT in some way X, then

• The SUT should respond with R and

• The SUT should be in state S2.

test context

Everything a system under test (SUT) needs to have in place so that we can ex-

ercise the SUT for the purpose of verifying its behavior. For this reason, RSpec

calls the test ﬁ xture (as used in xUnit) a “context.”

Context: a set fruits with

contents = {apple, orange, pear}

Exercise: remove orange from the fruits set

Verify: fruits set contents = {apple, pear}

In this example, the ﬁ xture consists of a single set and is created directly in the

test. How we choose to construct the ﬁ xture has very far-reaching ramiﬁ cations

for all aspects of test writing and maintenance.

test database

A database instance that is used primarily for the execution of tests. It should

not be the same database as is used in production!

test debt

I ﬁ rst became aware of the concept of various kinds of debts via the Industrial

XP mailing list on the Internet. The concept of “debt” is a metaphor for “not

doing enough of” something. To get out of debt, we must put extra effort into

the something we were not doing enough of. Test debt arises when we do not

write all of the necessary tests. As a result, we have “unprotected code” in that

the code could break without causing any tests to fail.

test-driven bug ﬁ xing

A way of ﬁ xing bugs that entails writing and automating unit tests that reproduce

each bug before we begin debugging the code and ﬁ xing the bug; the bug-ﬁ xing

extension of test-driven development.

812

Glossary

test-driven development (TDD)

A development process that entails writing and automating unit tests before the

development of the corresponding units begins. TDD ensures that the responsi-

bilities of each software unit are well understood before they are coded. Unlike

test-ﬁ rst development, test-driven development is typically meant to imply that

the production code is made to work one test at a time (a characteristic called

emergent design).

See also: ﬁ xture (Fit).

test ﬁ xture (in NUnit)

In NUnit (and in VbUnit and most .NET implementations of xUnit): The Test-

case Class on which the Test Methods are implemented. We add the attribute

[TestFixture] to the class that hosts the Test Methods.

Some members of the xUnit family assume that an instance of the Testcase

Class “is a” test context; NUnit is a good example. This interpretation assumes

we are using the Testcase Class per Fixture approach to organizing the tests.

When we choose to use a different way of organizing the tests, such as Testcase

Class per Class or Testcase Class per Feature, this merging of the concepts of

test context and Testcase Class can be confusing. This book uses “test ﬁ xture”

to mean “the pre-conditions of the test” (also known as the test context) and

Testcase Class to mean “the class that contains the Test Methods and any code

needed to set up the test context.”

test ﬁ xture (in xUnit)

In xUnit: All the things we need to have in place to run a test and expect a par-

ticular outcome (i.e., the test context). Some variants of xUnit keep the concept

of the test context separate from the Testcase Class that creates it; JUnit and its

direct ports fall into this camp. Setting up the test ﬁ xture is the ﬁ rst phase of the

Four-Phase Test. For meanings of the term “test ﬁ xture” in other contexts, see

test ﬁ xture (disambiguation).

Glossary

814

Also known as:

Testcase Class

Also known as:

test context

test-last development

A development process that entails executing unit tests after the development of

the corresponding units is ﬁ nished. Unlike test-ﬁ rst development, test-last devel-

opment merely says that testing should be done before the code goes into pro-

duction; it does not imply that the tests are automated. Traditional QA (quality

assurance) testing is inherently test-last development unless the tests are pre-

pared as part of the requirements phase of the project and are shared with the

development team.

test maintainer

The person or project role responsible for maintaining the tests as the system

or application evolves. Most commonly, this person is enhancing the system

with new functionality or ﬁ xing bugs. The test maintainer could also be who-

ever is called in when the automated tests fail for whatever reason. If the test

maintainer is doing the enhancements by writing tests ﬁ rst, he or she is also a

test driver.

test package

In languages that provide packages or namespaces, a package or name that

exists for the purpose of hosting Testcase Classes.

test reader

Anyone who has reason to read tests, including a test maintainer or test driver.

This individual may be reading the tests primarily for the purpose of under-

standing what the system under test (SUT) is supposed to do (Tests as Docu-

mentation) or as part of a test maintenance or software development activity.

test result

A test or test suite can be run many times, each time yielding a different test

result.

test run

A test or test suite can be run many times, each time yielding a different test

result. Some commercial test automation tools record the results of each test run

for prosperity.

Glossary

815

test smell

A symptom of a problem in test code. A smell doesn’t necessarily tell us what is

wrong because it may have several possible causes. Like all smells, a test smell

must pass the “sniffability test”—that is, it must grab us by the nose and say,

“Something is wrong here.”

test-speciﬁ c equality

Tests and the system under test (SUT) may have different ideas about what con-

stitutes equality of two objects. In fact, this understanding may differ from one

test to another. It is not advisable to modify the deﬁ nition of equality within the

SUT to match the tests’ expectations, as this practice leads to Equality Pollution.

Making individual Equality Assertions on many attributes of an object is not the

answer either, as it can result in Obscure Tests and Test Code Duplication. In-

stead, build one or more Custom Assertions that meets your tests’ needs.

test stripper

A step or program in the build process that removes all the test code from the

compiled and linked executable.

test success

A situation in which a test is run and all actual outcomes match the expected

outcomes. Compare with test failure and test error.

test suite

A way to name a collection of tests that we want to run together.

Uniﬁ ed Modeling Language (UML)

From Wikipedia [Wp]: “[A] nonproprietary speciﬁ cation language for object

modeling. UML is a general-purpose modeling language that includes a stan-

dardized graphical notation used to create an abstract model of a system,

referred to as a UML model.”

Glossary

816

unit test

A test that veriﬁ es the behavior of some small part of the overall system. What

turns a test into a unit test is that the system under test (SUT) is a very small subset

of the overall system and may be unrecognizable to someone who is not involved

in building the software. The actual SUT may be as small as a single object or

method that is a consequence of one or more design decisions, although its behav-

ior may also be traced back to some aspect of the functional requirements. Unit

tests need not be readable, recognizable, or veriﬁ able by the customer or business

domain expert. Contrast this with a customer test, which is derived almost entirely

from the requirements and which should be veriﬁ able by the customer. In eXtreme

Programming, unit tests are also called developer tests or programmer tests.

use case

A way of describing the functionality of a system in terms of what its users are

trying to achieve and what the system needs to do to achieve their goals. Unlike

user stories, use cases may cover many different scenarios yet are often not test-

able independently.

user acceptance test (UAT)

See acceptance test.

user story

The unit of incremental development in eXtreme Programming. We must INVEST

in good user stories—that is, each user story must be Independent, Negotiable,

Valuable, Estimatable, Small, and Testable [XP123]. A user story corresponds

roughly to a “feature” in non-eXtreme Programming terminology and is typically

decomposed into one or more tasks to be carried out by project team members.

verify outcome

After the exercise SUT phase of the test, the test compares the actual outcome—

including returned values, indirect outputs, and the post-test state of the system

under test (SUT)—with the expected outcome. This phase of the test is called

the verify outcome phase.

Also known as:

story, feature

Glossary

817