Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
788
Glossary
(e.g., “test” becomes “spec”; “fi xture” becomes “context”) and more explicit
framework support for clarity of the specifi cation.
behavior smell
A test smell we encounter while compiling or running tests. We don’t have to be
particularly observant to notice behavior smells, as they will present themselves
to us via compile errors or test failures. See also: code smell, project smell.
black box
A piece of software that we treat as an opaque object whose internal workings
cannot be seen. Tests written for the black box can verify only externally visible
behavior and are independent of the implementation inside the system under
test (SUT).
block
A block of code that can be run. Many programming languages (most notably,
Smalltalk and Ruby) use blocks (also known as “block closures”) as a way of
passing a chunk of code to a method, which can then run the code in its own
context. Java’s anonymous inner classes are a way to achieve the same thing
without direct support for blocks. C# uses delegates for the same purpose.
block closure
See block.
boundary value
An input value for a system under test (SUT) that is immediately adjacent to the
boundary between two equivalence classes. Tests using two adjacent boundary
values help us verify that the behavior changes with exactly the right input and
that we don’t have “off by one” problems.
built-in self-test
A means of organizing test code in which the tests live inside the same module
or class as the production code and are run automatically when the system is
initialized.
789
Glossary
business logic
The core logic related to the domain model of a business system. Because busi-
ness logic usually refl ects the results of many independent business decisions, it
often seems anything but logical!
class attribute
An attribute that is placed on a class in the source code to tell the compiler or
runtime system that this class is “special.” In some variants of xUnit, class at-
tributes are used to indicate that a class is a Testcase Class.
class method
A method that is associated with a class rather than an object. Class methods can be
invoked using a classname.methodname notation [e.g., Assert.assertEquals(message,
expected, actual);
] and do not require an instance of the class to be invoked. Class
methods cannot access instance methods or instance variables of objects; that is,
they do not have access to self or this. In Java, a class method is called a static
method. Other languages may use different names or keywords.
class variable
A variable that is associated with a class rather than an instance of the class and
is typically used to access information that all instances need to share. In some
languages, class variables can be accessed using the syntax classname.variable-
name (e.g., TestHelper.lineFeedCharacter;). That is, they do not need to be accessed
via self or this. In Java, a class variable is called a static variable. Other lan-
guages may use different names or keywords.
closure
See block.
code smell
The “classic” bad smell, as fi rst described by Martin Fowler in [Ref]. Test au-
tomaters must recognize code smells that arise as they maintain test code. Code
smells typically affect maintenance cost of tests but may also be early warning
signs of behavior smells to follow.
See also: test smell, behavior smell, project smell.
790
Glossary
component
A larger part of the overall system that is often separately deployable. Component-
based development involves decomposing the overall functionality into a series
of individual components that can be built and deployed separately. This allows
sharing of the components between applications that need the same functionality.
Each component is a consequence of one or more design decisions, although its
behavior may also be traced back to some aspect of the requirements.
Components can take many forms, depending on the technology being
employed. The Windows platform uses dynamic linked libraries (DLLs) or
assemblies as components. The Java platform uses Java Archives (JARs). A
service-oriented architecture (SOA) uses Web Services as its large-grained
components. The components may implement front-end logic (e.g., a “File
Open Dialog”) or back-end logic (e.g., a “Customer Persistence” component).
A component can and should be verifi ed using component tests before the
overall application is tested using customer tests.
component test
A test that verifi es the behavior of some component of the overall system. The
component is a consequence of one or more design decisions, although its be-
havior may also be traced back to some aspect of the requirements. There is
no need for component tests to be readable, recognizable, or verifi able by the
customer or business domain expert. Contrast this with a customer test, which
is derived almost entirely from the requirements and should be verifi able by
the customer, and with a unit test, which verifi es a much smaller component. A
component test lies somewhere in between these two extremes.
During test-driven development, component tests are written after the cus-
tomer tests are written and the overall design is solidifi ed. They are written as
the architectural decisions are made but before the individual units are designed
or coded. They are usually automated using a member of the xUnit family.
constructor
A special method used in some object-oriented programming languages to con-
struct a brand-new object. It often has the same name as the class and is typically
called automatically by the runtime system whenever the special operation new is
invoked. A Complete Constructor Method [SBPP] returns a ready-to-use object
that requires no additional tweaking; this usually implies arguments must be
passed to the constructor.
791
Glossary
continuous integration
The agile software development practice of integrating software changes continu-
ously. In practice, developers typically integrate their changes every few hours to
days. Continuous integration often includes the practice of an automated build
that is triggered by each check-in. The build process typically runs all automated
tests and may even run tests that aren’t run before check-in because they take
too long. The build is considered to have “failed” if any tests fail. When the
build fails, teams typically consider getting the build working again to be the top
priority; only code changes aimed at fi xing the build are allowed until a successful
build has occurred.
control point
How the test asks the system under test (SUT) to do something for it. A control
point could be created for the purpose of setting up or tearing down the fi xture
or it could be used during the exercise SUT phase of the test. It is a kind of in-
teraction point. Some control points are provided strictly for testing purposes;
they should not be used by the production code because they bypass input
validation or short-circuit the normal life cycle of the SUT or some object on
which it depends.
customer test
A test that verifi es the behavior of a slice of the visible functionality of the over-
all system. The system under test (SUT) may consist of the entire system or a
fully functional top-to-bottom slice (“module”) of the system. A customer test
should be independent of the design decisions made while building the SUT.
That is, we should require the same set of customer tests regardless of how we
choose to build the SUT. (Of course, how the customer tests interact with the
SUT may be affected by high-level software architecture decisions.)
data access layer
A way of keeping data access logic from permeating the application code by put-
ting it into a separate component that encapsulates the database.
depended-on component (DOC)
An individual class or a large-grained component on which the system under
test (SUT) depends. The dependency is usually one of delegation via method
Also known as:
data access
object (DAO),
data abstraction
layer (DAL)
792
Glossary
calls. In test automation, the DOC is primarily of interest in that we need to be
able to observe and control its interactions with the SUT to get complete test
coverage.
design pattern
A pattern that we can use to solve a particular software design problem. Most
design patterns are programming language independent; the language-specifi c
ones are typically called “coding idioms.” Design patterns were fi rst popularized
by the book Design Patterns [GOF].
design for testability
A way of ensuring that code is easily tested by making sure that testing require-
ments are considered as the code is designed. When doing test-driven develop-
ment, design for testability occurs as a natural side effect of development
developer test
Another name for an automated unit test that is prepared by someone playing
the developer role on an eXtreme Programming project.
DfT
See design for testability.
direct input
A test may interact with the system under test (SUT) directly via its “front door”
or public application programming interface (API) or indirectly via its “back
door.” The stimuli injected by the test into the SUT via its front door are direct
inputs of the SUT. Direct inputs may consist of method or function calls to an-
other component or messages sent on a message channel (e.g., MQ or JMS) and
the arguments or contents thereof.
direct output
A test may interact with the system under test (SUT) directly via its “front door”
or public application programming interface (API) or indirectly via its “back
door.” The responses received by the test from the SUT via its front door are
Also known as:
DfT
793
Glossary
direct outputs of the SUT. Direct outputs may consist of the return values of
method or function calls, updated arguments passed by reference, exceptions
raised by the SUT, or messages received on a message channel (e.g., MQ or JMS)
from the SUT.
document-driven development
A development process that focuses on producing documents that describe
how the code will be structured and then coding from those documents. Docu-
ment-driven development is normally associated with “big design up front”
(BDUF, also known as “waterfall”) software development. Contrast this with
test-driven development, which focuses on producing working code one test
at a time.
domain layer
The layer of a Layered Architecture [DDD, PEAA, WWW] that corresponds to
the domain model. See Eric Evans’ book, Domain-Driven Design [DDD].
domain model
A model of the problem domain that may form the basis of the object model
in the business domain layer of a software application. See Eric Evans’ book,
Domain-Driven Design [DDD].
DTO
Short for the Data Transfer Object [CJ2EEP] design pattern.
dynamic binding
Deferring the decision about which piece of software to transfer control to until
execution time. The same method name can be used to invoke different behavior
(method bodies) based on the class of the object on which it is invoked; the latter
class is determined only at execution time. Dynamic binding is the opposite of
static binding; it is also called polymorphism (from the Latin, meaning “taking
on many shapes”).
EDD
See example-driven development.
emergent design
The opposite of BDUF (big design up front). Emergent design involves letting
the right design be discovered as the software slowly evolves to pass one test at
a time during test-driven development.
endoscopic testing
A testing technique pioneered by the authors of the original Mock Object paper
[ET], which involves testing software from the inside.
entity object
An object that represents an entity concept from a domain. Entity objects typi-
cally have a life cycle that is represented as their state. Contrast this with a
service object, which has no single state. EJB Entity Beans are one example of
an entity object.
equivalence class
A test condition identifi cation technique that reduces the number of tests
required by grouping together inputs that should result in the same output or
that should exercise the same logic in the system. This organization allows
us to focus our tests on key boundary values at which the expected output
changes.
example-driven development (EDD)
A reframing of the test-driven development process to focus on the “executable
specifi cation” aspect of the tests. The act of providing examples is more intuitive
to many people; it doesn’t carry the baggage of “testing” software that doesn’t
yet exist.
exercise SUT
After the fi xture setup phase of testing, the test stimulates the system under
test (SUT) logic that is to be tested. This phase of the testing process is called
exercise SUT.
Also known as:
domain object
Glossary
794
expectation
What a test expects the system under test (SUT) to have done. When we are
using Mock Objects to verify the indirect outputs of the SUT, we load each
Mock Object with the expected method calls (including the expected argu-
ments); these are called the expectations.
expected outcome
The outcome that we verify after exercising the system under test (SUT).
A Self-Checking Test verifi es the expected outcome using calls to Assertion
Methods.
exploratory testing
Interactive testing of an application without a specifi c script in hand. The tester
“explores” the system, making up theories about how it should behave based
on what the application has already done and then testing those theories to see
if they hold up. While there is no rigid plan, exploratory testing is a disciplined
activity that is more likely to fi nd real bugs than rigidly scripted tests.
eXtreme Programming
An agile software development methodology that showcases pair programming,
automated unit testing, and short iterations.
factory
A method, object, or class that exists to build other objects.
false negative
A situation in which a test passes even though the system under test (SUT) is
not working properly. Such a test is said to give a false-negative indication or a
“false pass.”
See also: false positive.
false positive
A situation in which a test fails even though the system under test (SUT) is
working properly. Such a test is said to give a false-positive indication or a
Glossary
795
“false failure.” The terminology comes from statistical science and relates to
our attempt to calculate the probability of some observation error occurring.
For example, in medicine we run tests to fi nd out if a medical condition is pres-
ent; if it is, the test is “positive.” It is useful to know the probability that a test
might indicate that a condition (such as diabetes) is present when it is not—that
is, a false “positive.” If we think of software tests as a way of determining
whether a condition (a particular defect or bug) is present, a test that reports a
defect (a test failure or error) when it is not, in fact, present is giving us a false
positive.
See also: false negative. Wikipedia [Wp] has an extensive description under
the topic “Type I and type II errors.”
fault insertion test
A kind of test in which a deliberate fault is introduced in one part of the sys-
tem to verify that another part reacts to the error appropriately. Initially, the
faults were related to hardware but the same concept is now applied to software
faults as well. Replacing a depended-on component (DOC) with a Saboteur that
throws an exception is an example of a software fault insertion test.
feature
A testable unit of functionality that can be built onto the evolving software sys-
tem. In eXtreme Programming, a user story corresponds roughly to a feature.
Fit test
A test that uses the Fit testing framework; most commonly a customer test.
fi xture
See test fi xture (disambiguation).
fi xture (Fit)
In Fit, the Adapter [GOF] that interprets the Fit table and invokes methods on
the system under test (SUT), thereby implementing a Data-Driven Test. For
meanings in other contexts, see test fi xture (disambiguation), test fi xture (in
xUnit), and test fi xture (in NUnit).
Glossary
796
fi xture holding class variable
A class variable of a Testcase Class that is used to hold a reference to the test
fi xture. It typically holds a reference to a Shared Fixture.
fi xture holding instance variable
An instance variable of a Testcase Object that is used to hold a reference to the
test fi xture. It typically holds a reference to a Fresh Fixture that is set up using
Implicit Setup.
fi xture holding local variable
A local variable of a Test Method that is used to hold a reference to the test fi x-
ture. It typically holds a reference to a Fresh Fixture that is set up within the test
method using In-line Setup or returned from Delegated Setup.
fi xture setup
Before the desired logic of the system under test (SUT) can be exercised, the pre-
conditions of the test need to be set up. Collectively, all objects (and their states)
are called the test fi xture (or test context), and the phase of the test that sets up
the test fi xture is called fi xture setup.
fi xture teardown
After a test is run, the test fi xture that was built by the test should be destroyed.
This phase of the test is called fi xture teardown.
fl uent interface
A style of object constructor API that results in easy-to-understand statements.
The Confi guration Interface provided by the Mock Object toolkit JMock is an
example of a fl uent interface.
front door
The public application programming interface (API) of a piece of software. Con-
trast this with the back door.
Glossary
797