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.

Pre`con*di"tion (?), n.

A previous or antecedent condition; a preliminary condition.


© Webster 1913.

Log in or registerto write something here or to contact authors.