Meszaros G. xUnit Test Patterns Refactoring Test Code

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

function pointer

From Wikipedia [Wp]: “A function pointer is a type of pointer in C, C++, D, and

other C-like programming languages. When dereferenced, a function pointer in-

vokes a function, passing it zero or more arguments like a normal function.”

functional test (common usage)

A black-box test of the end-user functionality of an application. The agile com-

munity is trying to avoid this usage of “functional test” because of the potential for

confusion when talking about verifying functional (as opposed to nonfunctional or

extra-functional properties) properties of a unit or component. This book uses the

terms “customer test” and “acceptance test” for a functional test of the entire appli-

cation and “unit test” for a functional test of an individual unit of the application.

functional test (contrast with extra-functional test)

A test that veriﬁ es the functionality implemented by a piece of software. De-

pending on the scope of the software, a functional test may be a customer test,

a unit test, or a component test.

In some circles a functional test is a customer test. This usage becomes con-

fusing, however, when we talk about testing nonfunctional or extra-functional

properties of the system under test (SUT). This book uses the terms “customer

test” and “acceptance test” for a functional test of the entire application and

“unit test” for a functional test of an individual unit of the application.

garbage collection

A mechanism that automatically recovers the memory used by any objects that

are no longer accessible. Many modern object-oriented programming environ-

ments provide garbage collection.

global variable

A variable that is global to a whole program. A global variable is accessible

from anywhere within the program and never goes out of scope, although the

memory to which it refers can be deallocated explicitly.

green bar

Many Graphical Test Runners portray the progress of the test run using a prog-

ress bar. As long as all tests have passed, the bar stays green. When any tests fail,

the indicator changes to a red bar.

Also known as:

procedure

variable,

delegate in

.NET languages

Glossary

798

GUI

Graphical user interface.

happy path

The “normal” path of execution through a use case or through the software that

implements it; also known as the “sunny day” scenario. Nothing goes wrong,

nothing out of the ordinary happens, and we swiftly and directly achieve the

user’s or caller’s goal.

Hollywood principle

What directors in Hollywood tell aspiring actors at mass-casting calls: “Don’t

call us; we’ll call you (if we want you).” In software, this concept is often called

inversion of control (IOC).

IDE

Integrated development environment. An environment that provides tools to edit,

compile, execute, and (typically) test code within a single development tool.

incremental delivery

A method of building and deploying a software system in stages and releasing

the software as each stage, called an “increment,” is completed. This approach

results in earlier delivery to the user of a working system, where the capabilities

of the system increase over time. In agile methods, the increment of functionality

is the feature or user story. Incremental delivery goes beyond iterative develop-

ment and incremental development, however, by actually putting the functional-

ity into production on a regular basis. This idea is summarized by the following

mantra: “Deliver early, deliver often.”

incremental development

A method of building a software system in stages such that the functionality built

to date can be tested before the next stage is started. This approach allows for

the earlier delivery to the user of a working system, where the capabilities of the

system increase over time (see incremental delivery). In agile methods, the incre-

ment of functionality is the feature or user story. Incremental development goes

beyond iterative development, however, in that it promises to produce working,

Glossary

799

testable, and potentially deployable software with every iteration. With incre-

mental delivery, we also promise to “Deliver early, deliver often.”

indirect input

When the behavior of the system under test (SUT) is affected by the values returned

by another component whose services it uses, we call those values the indirect in-

puts of the SUT. Indirect inputs may consist of actual return values of functions,

updated (out) parameters of procedures or subroutines, and any errors or excep-

tions raised by the depended-on component (DOC). Testing of the SUT behavior

with indirect inputs requires the appropriate control point on the “back side” of

the SUT. We often use a Test Stub to inject the indirect inputs into the SUT.

indirect output

When the behavior of the system under test (SUT) includes actions that cannot

be observed through the public application programming interface (API) of the

SUT but that are seen or experienced by other systems or application compo-

nents, we call those actions the indirect outputs of the SUT. Indirect outputs

may consist of method or function calls to another component, messages sent

on a message channel (e.g., MQ or JMS), and records inserted into a database or

written to a ﬁ le. Veriﬁ cation of the indirect output behaviors of the SUT requires

the use of appropriate observation points on the “back side” of the SUT. Mock

Objects are often used to implement the observation point by intercepting the

indirect outputs of the SUT and comparing them to the expected values.

See also: outgoing interface.

inner class

A class in Java that is deﬁ ned inside another class. Anonymous inner classes are

deﬁ ned inside a method, whereas inner classes are deﬁ ned outside a method. In-

ner classes are often used when deﬁ ning Hard-Coded Test Doubles.

instance method

A method that is associated with an object rather than the class of the object. An

instance method is accessible only from within or via an instance of the class.

It is typically used to access information that is expected to differ from one

instance to another.

Also known as:

outgoing

interface

800

Glossary

Also known as:

member

variable

The exact syntax used to access an instance method varies from language to

language. The most common syntax is objectReference.methodName(). When

referenced from within other methods on the object, some languages require an

explicit reference to the object (e.g., this.methodName() or self methodName);

other languages simply assume that any unqualiﬁ ed references to methods are

references to instance methods.

instance variable

A variable that is associated with an object rather than the class of object. An instance

variable is accessible only from within or via an instance of the class. It is typically

used to access information that is expected to differ from one instance to another.

interaction point

A point at which a test interacts with the system under test (SUT). An interac-

tion point can be either a control point or an observation point.

interface

In general, a fully abstract class that deﬁ nes only the public methods that all im-

plementers of the interface must provide. In Java, an interface is a type deﬁ nition

that does not provide any implementation. In most single-inheritance languages,

a class may implement any number of interfaces, even though it can extend

(subclass) only one other class.

inversion of control (IOC)

A control paradigm that distinguishes software frameworks from “toolkits” or

components. The framework calls the software plug-in (rather than the reverse).

In the real world, inversion of control is often called the Hollywood principle.

With the advent of automated unit testing, a class of framework known as an

inversion of control framework has sprung up speciﬁ cally to simplify the re-

placement of depended-on components (DOCs) with Test Doubles.

IOC

See inversion of control.

Also known as:

member

function

Glossary

801

iterative development

A method of building a software system using time-boxed “iterations.” Each

iteration is planned and then executed. At the end of the “time box,” the status

of all the work is reviewed and the next iteration is planned. The strict time-

boxing prevents “runaway development,” where the state of the system is never

assessed because nothing is ever ﬁ nished. Unlike incremental development, itera-

tive development does not require working software to be delivered at the end

of each iteration.

layer-crossing test

A test that either sets up the ﬁ xture or veriﬁ es the outcome using Back Door

Manipulation, which involves using a “back door” of the system under test

(SUT) such as a database. Contrast this with a round-trip test.

legacy software

In the test-driven development community, any software that does not have a

Safety Net of Fully Automated Tests.

liveware

The people who use our software. They are usually assumed to be much more

intelligent than either the software or the hardware but they can also be rather

unpredictable.

local variable

A variable that is associated with a block of code rather than an object or class.

A local variable is accessible only from within the code block; it goes out of

scope when the block of code returns to its caller.

manual test

A test that is executed by a person interacting with the system under test (SUT).

The user may be following some sort of “test script” (not to be confused with a

Scripted Test) or doing ad hoc or exploratory testing.

Also known as:

wetware,

mushware

Glossary

802

meta object

An object that holds data that controls the behavior of another object. A meta

object protocol is the interface by which the meta object is constructed or con-

ﬁ gured.

metatest

A test that veriﬁ es the behavior of one or more tests. Such a test is mostly used

during test-driven development, when we are writing tests as examples or course

material and we want to ensure that tests are, indeed, failing to illustrate a par-

ticular problem.

method attribute

An attribute that is placed on a method in the source code to tell the compiler

or runtime system that this method is “special.” In some xUnit family members,

method attributes are used to indicate that a method is a Test Method.

mixin

Functionality intended to be inherited by another class as part of that class’s

implementation without implying specialization (“kind of” relationship) of the

providing class.

“The term mixin comes from an ice cream store in Somerville, Massachu-

setts, where candies and cakes were mixed into the basic ice cream ﬂ avors. This

seemed like a good metaphor to some of the object-oriented programmers who

used to take a summer break there, especially while working with the object-

oriented programming language SCOOPS” (SAMS Teach Yourself C++ in 21

Days, 4th ed., p. 458).

module

In legacy programming environments (and probably a few current ones, too):

An independently compilable unit of source code (e.g., the “ﬁ le I/O module”)

that is later linked into the ﬁ nal executable. Unlike a component, this kind of

module is typically not independently deployable. It may or may not have a cor-

responding set of unit tests or component tests.

When describing the functionality of a software system or application: A

complete vertical chunk of the application that provides a particular piece of

functionality (e.g., the “Customer Management Module”) that can be used

Glossary

803

somewhat independently of the other modules. It would have a corresponding

set of acceptance tests and may be the unit of incremental delivery.

need-driven development

A variation on the test-driven development process where code is written from the

outside in and all depended-on code is replaced by Mock Objects that verify the

expected indirect outputs of the code being written. This approach ensures that

the responsibilities of each software unit are well understood before they are

coded, by virtue of having unit tests inspired by examples of real usage. The

outermost layer of software is written using storytest-driven development. It

should have examples of usage by real clients (e.g., a user interface driving the

Service Facade [CJ2EEP]) in addition to the customer tests.

object-relational mapping (ORM)

A middleware component that translates between the object-oriented domain

model of an application and the table-oriented view presented by a relational

database management system.

observation point

The means by which the test observes the behavior of the system under test

(SUT). This kind of interaction point can be used to inspect the post-exercise

state of the SUT or to monitor interactions between the SUT and its depended-

on components. Some observation points are provided strictly for the tests; they

should not be used by the production code because they may expose private

implementation details of the SUT that cannot be depended on not to change.

ORM

See object-relational mapping.

outgoing interface

A component (e.g., a class or a collection of classes) often depends on other

components to implement its behavior. The interfaces it uses to access these

components are known as outgoing interfaces, and the inputs and outputs trans-

mitted via test interfaces are called indirect inputs and indirect outputs. Outgoing

interfaces may consist of method or function calls to another component, mes-

sages sent on a message channel (e.g., MQ or JMS), or records inserted into a

Glossary

804

database or written to a ﬁ le. Testing the behavior of the system under test (SUT)

with outgoing interfaces requires special techniques such as Mock Objects to

intercept and verify the usage of outgoing interfaces.

pattern

A solution to a recurring problem. A pattern has a context in which it is typically

applied and forces that help you choose one pattern over another based on that

context. Design patterns are a particular kind of pattern. Organizational pat-

terns are not discussed in this book.

pattern language

A collection of patterns that work together to lead the reader from a very high-

level problem to a very detailed solution customized for his or her particular

context. When a pattern language achieves this goal, it is said to be “genera-

tive”; this characteristic differentiates a pattern language from a simple collec-

tion of patterns. Refer to “A Pattern Language for Pattern Writing” [APLfPW]

to learn more about how to write a pattern language.

polymorphism

Dynamic binding. The word is derived from the Latin, meaning “taking on

many shapes.”

presentation layer

The part of a Layered Architecture [DDD, PEAA, WWW] that contains the

presentation logic.

presentation logic

The logic embedded in the presentation layer of a business system. It decides

which screen to show, which items to put on menus, which items or buttons to

enable or disable, and so on.

procedure variable

A variable that refers to a procedure or function rather than a piece of data.

It allows the code to be called to be determined at runtime (dynamic binding)

rather than at compile time. The actual procedure to be invoked is assigned to

Also known as:

function pointer,

delegate

(in .NET

languages)

Glossary

805

the variable either during program initialization or during execution. Procedure

variables were a precursor to true object-oriented programming languages

(OOPLs). Early OOPLs such as C++ were built by using tables (arrays) of data

structures containing procedure variables to implement the method (member

function) dispatch tables for classes.

production

In IT shops, the environment in which applications being used by real users run.

This environment is distinguished from the various testing environments, such

as “acceptance,” “integration,” “development,” and “qual” (short for “quality

assessment or assurance”).

production code

In IT shops, the environment in which applications run is often called produc-

tion. Production code is the code that we are writing for eventual deployment

to this environment, whether the code is to be shipped in a product or deployed

into “production.” Compare to “test code.”

programmer test

A developer test.

project smell

A symptom that something has gone wrong on the project. Its underlying root

cause is likely to be one or more code smells or behavior smells. Because project

managers rarely run or write tests, project smells are likely the ﬁ rst hint they

have that something may be less than perfect in test automation land.

pull

A concept from lean manufacturing that states that things should be produced

only once a real demand for them exists. In a “pull system,” upstream (i.e.,

subcomponent) assembly lines produce only enough products to replace the

items withdrawn from the pool that buffers them from the downstream assem-

bly lines. In software development, this idea can be translated as follows: “We

should only write methods that have already been called by other software and

only handle those cases that the other software actually needs.” This approach

avoids speculation and the writing of unnecessary software, which is one of

Also known as:

pull system

Glossary

806

software development’s key forms of inventory (which is considered waste in

lean systems).

red bar

Many Graphical Test Runners portray the progress of the test run using a prog-

ress bar that starts off green in color. When any tests fail, this indicator changes

to a red bar.

refactoring

Changing the structure of existing code without changing its behavior. Refactor-

ing is used to improve the design of existing code, often as a ﬁ rst step before add-

ing new functionality. The authoritative source for information on refactoring is

Martin Fowler’s book [Ref].

reﬂ ection

The ability of a software program to examine its own structure as it is executing.

Reﬂ ection is often used in software development tools to facilitate adding new

capabilities.

regression test

A test that veriﬁ es that the behavior of a system under test (SUT) has not

changed. Most regression tests are originally written as either unit tests or ac-

ceptance tests, but are subsequently included in the regression test suite to keep

that functionality from being accidentally changed.

result veriﬁ cation

After the exercise SUT phase of the Four-Phase Test, the test veriﬁ es that the

expected (correct) outcome has actually occurred. This phase of the test is called

result veriﬁ cation.

retrospective

A process whereby a team reviews its processes and performance for the pur-

pose of identifying better ways of working. Retrospectives are often conducted

at the end of a project (called a project retrospective) to collect data and make

recommendations for future projects. They have more impact if they are done

Also known as:

postmortem,

postpartum

Glossary

807