In software engineering, a explicit logical statement that must evaluate to true on entry of
a method or component. (Compare with postcondition and invariant). In the
design by contract paradigm, pioneered by the Eiffel language, preconditions are embodied
as formal assertions that are tested on method entry. Failure of a
precondition usually denotes an error on the part of the caller or "client".
Many preconditions, such as the calling convention or correct data type for
input parameters, may be enforced via a software development
best practice such as coding to interfaces. In this case, the correctness of the
precondition is tested when the calling code is first examined, such as in a
compilation step. However, other types of preconditions exist - often, software
components are brittle because some simple candidates for preconditions (such as
"the password cannot be an empty string") remain implicit, and the behavior of
the component following a violation of that precondition is unspecified.
Considerable synergy exists between the development of thorough preconditions and
black box testing. A requirement of a test plan is definition of the valid inputs
and the corresponding expected output. Preconditions can be used to specify which
inputs should be considered as valid, and fail fast when violated. | 
