How does a postcondition differ from a unit test assertion?

A postcondition is a formal part of a method's specification that defines its correct behavior for all valid inputs. It is a design-time declaration. A unit test assertion verifies the code's behavior for a specific set of example inputs defined in a test case. A unit test might be written to check if a postcondition holds for a particular scenario, but the postcondition itself is the general rule the code must follow.

If a method's postcondition fails, where is the bug most likely located?

If a method's postcondition fails (and its precondition was met), the bug is located inside that method. The failure signifies that the method did not fulfill its contractual promise to produce the correct outcome or state.

Postcondition

Q: What is the relationship between a precondition and a postcondition in Design by Contract?

A precondition is a condition that must be true before a method is called; it is the responsibility of the caller. A postcondition is a condition that must be true after the method completes; it is the responsibility of the method itself. The contract states that a method only guarantees its postcondition if the caller has already satisfied the precondition.

Intermediate

A postcondition is a condition or predicate that must always be true immediately after the execution of a piece of code. It is a core component of Design by Contract, representing the 'guarantee' a method makes if its preconditions were met.

First used·Mid-1980s

Definitions·1

Synonyms·3

Category·Software Engineering

Also known as

Post-assertionExit conditionEnsure clause

Definitions

What it means.

01
Postcondition in Software Engineering
In software engineering, a postcondition is a predicate or condition that is guaranteed to be true immediately after a piece of code, such as a function, method, or block, has finished executing. It is a fundamental concept in the Design by Contract (DbC) programming methodology.

A postcondition defines the 'guarantee' or 'promise' part of a contract. It specifies the state of the system after the operation is complete. This includes the state of the object, the function's return value, and any other side effects. The method is only obligated to fulfill its postcondition if the caller met the corresponding precondition (the requirements before execution).

Key Concepts

Contractual Obligation: A method's implementation is considered correct if it ensures the postcondition holds true upon its completion, assuming the precondition was met at the start.

Documentation: Postconditions serve as precise, verifiable documentation. They clearly state what a method accomplishes, which is often more useful than describing how it does it.

Debugging: When a postcondition fails during runtime checks, it points directly to a bug within the executed method. This significantly simplifies debugging by pinpointing the source of the error.

Implementation: In practice, postconditions are often implemented using assert statements or language-specific keywords. For example, the Eiffel language uses the ensure keyword to define postconditions. In other languages, they might be specified in comments, annotations (e.g., Java Modeling Language), or checked within unit tests.

Example (in pseudocode)

Consider a pop method for a Stack data structure.

method pop() from Stack: precondition: not self.isEmpty() postcondition: self.count() == old self.count() - 1

Here, the postcondition guarantees that after pop is called, the number of items in the stack will be exactly one less than it was before the call. The old keyword is often used in DbC to refer to a value as it was at the beginning of the method's execution.

Origin

Where it comes from.

Etymology

The term is a compound of the Latin prefix 'post-', meaning 'after', and 'condition', from the Latin 'condicio', meaning 'agreement' or 'stipulation'. Thus, it literally means 'a condition that applies after' an event.

Historical context

The conceptual roots of postconditions lie in early work on program correctness and formal verification from the 1960s. Computer scientists like Robert Floyd and Tony Hoare developed formal systems (like Hoare logic) that used assertions, including postconditions, to mathematically prove program correctness.

However, the term and its practical application were popularized and formalized by Bertrand Meyer in the mid-1980s as a central part of his Design by Contract (DbC) methodology and the Eiffel programming language. Meyer introduced the ensure keyword in Eiffel to explicitly define postconditions as a verifiable part of the code's interface, moving the concept from theoretical proofs to a practical software engineering tool.

Since then, the idea has influenced many areas of software development. It has inspired features like .NET's Code Contracts, the Java Modeling Language (JML), and the widespread use of assertions in programming and unit testing frameworks. While not all languages have first-class support for postconditions, the principle of specifying and verifying the state of a system after an operation remains a cornerstone of writing robust and reliable software.

Usage

In context.

The developer added a postcondition to the sort function to ensure the resulting array is always in ascending order.
A runtime error occurred because the database transaction violated its postcondition, leaving the data in an inconsistent state.
In Eiffel, the ensure clause is used to formally define the method's postcondition as part of its contract.
A critical exit condition for the closeFile function is that the file handle must be null after execution.

FAQ

Common questions.

A precondition is a condition that must be true before a method is called; it is the responsibility of the caller. A postcondition is a condition that must be true after the method completes; it is the responsibility of the method itself. The contract states that a method only guarantees its postcondition if the caller has already satisfied the precondition.

Taxonomy

What it means.

Postcondition in Software Engineering

Where it comes from.

In context.

Common questions.

Filed under.