Abstract class
A class that cannot be instantiated, because parts of its implementation are delegated to specific subclasses.
Acceptance test
In Extreme Programming (XP), an automated test defined by the customer to check for the extent the software meets the required functionality or the required properties (

See also User story.

Anticomposition axiom
An axiom about object-oriented testing stating that the sum of adequate test suites for segments of a module does not necessarily result in an adequate test suite for the entire module.
Antidecomposition axiom
An axiom about object-oriented testing stating that components can contain errors that may not be discovered by testing the system as a whole.
Antiextensionality axiom
An axiom about object-oriented testing stating that various implementations of a specification may require different test suites.
Abstract Windowing Toolkit. The original Java GUI library with components whose look and feel depend on the operating system used.
Black-box test
A specification-based test that looks at a system or unit exclusively from the outside, that is, over its public interface;

See also White-box test.

An approach used, for example, for testing or design, where a hierarchical problem or system is initially viewed from the finest decomposition step, then works upward to the more general. Opposite: Top-down.
A hint for the Java compiler to view an object as an instance of a subclass or interface. Although a cast avoids static typing, it often cannot be avoided because there are no generic types in Java.
Checked Exception
A Java exception that isn't being derived from RuntimeException. Such an exception has to be caught or listed in the throws clause.
Class invariant
A condition that has to be applicable for each instance of a class at any given time, that is, after execution of an arbitrary public method.

See also Design pattern.

Code smell
The unpleasant feeling you get when you see bad code.
Continuous integration
The integration of new code into the overall system several times a day. In contrast to what many developers believe, the integration effort decreases when you integrate more frequently.
Common Object Request Broker Architecture. An open, language-independent infrastructure for distributed components developed by the Object Management Group (OMG).
Class under test. The class on which a certain test case or test suite focuses.

See also OUT.

Design by contract. A paradigm stating that each software element (e.g., a method) specifies in a contract the pre-conditions it requires to run, the post-conditions it will ensure upon completion, and which invariants will remain.

See also Class invariant.

Defensive programming
A coding style that attempts to ensure that coding errors occurring in one place cannot cause unexpected results (e.g., program abort) in another place. Practices of defensive coding include mainly the avoidance of problematic language constructs and the definition of coding standards, but also checking of all input parameters of methods.
An object delegates a task to another object, where the message signature is normally maintained.
Dependency Inversion Principle
This principle states that general and abstract program modules should depend only upon abstract modules (interfaces) [Martin02b].
Delivery and installation of a software product.
Design pattern
A ready-to-use solution for a frequent design problem, expressed as partial design, consisting of classes and associations. Each design pattern is embedded in a set of constraints.
Document Object Model. A platform- and programming-language independent API standardized by the World Wide Web Consortium (W3C) for reading and modifying HTML and XML documents.