What Are Assumptions? #
In Fossil Test, assumptions are formal, traceable declarations of expectations that must be met during test execution. Unlike traditional assertions, which are often passive and silent when absent, assumptions are required to be acknowledged, evaluated, and reported—whether they pass, fail, or are simply unused. Each assumption is a contract: a binding declaration of what must be true, should be validated, and cannot be ignored.
Why “Assumption” Instead of “Assertion”? #
The term assumption was chosen deliberately to emphasize the proactive intent behind each check. Assertions, in many traditional test suites, are optional and often skipped entirely—especially in poorly written tests. These cases can create false positives where a test case runs but evaluates nothing, quietly passing without validating any behavior.
By contrast, an assumption in Fossil Test is always accounted for. It is treated as an explicit, traceable expectation. The name helps reinforce that:
- The test assumes something about state, logic, or input.
- Fossil Test will verify that this assumption is used.
- If the assumption is registered but never evaluated, Fossil Test will report it as a missing validation.
This prevents “hollow” test cases that appear legitimate but contain no meaningful checks—a subtle, recurring issue in test code-bases.
Enforcement: Making Ignored Assumptions Impossible #
Fossil Test introduces anomaly detection at the test engine level. It tracks all assumptions introduced into a test case system. If an assumption is not matched by an actual test evaluation—such as a numeric comparison, pointer check, or memory verification—it is marked as unused.
These unused assumptions are treated as anomalies, not mere oversights. They are flagged during the test summary, so developers can’t accidentally (or deliberately) skip critical validations. This closes a loophole that exists in many test frameworks: the ability to define a test case that contains no effective checks.
Assumptions Enable Precise and Typed Testing #
Assumptions are designed with typed semantics, making them ideal for both static and dynamic analysis. Types include:
- Boolean – test logical conditions or flags
- Numeric – validate exact or approximate numeric values
- Floating – compare floats with tolerance
- Memory – verify usage, lifecycle, and leaks
- Pointer – confirm validity and address correctness
- Range – ensure values fall within expected bounds
- String/Char – match or validate textual inputs
- SOAP/Anti-Rot – validate that long-term system stability, messaging correctness, or data fidelity is preserved
These types ensure assumptions carry meaning not only in execution but in the structure of your code-base, improving test transparency and reliability.
Designed for Accountability #
Tests that pass without any assumptions are considered suspicious by default. Fossil Test emits a warning or failure depending on configuration, alerting developers to the possibility of incomplete tests. This encourages accountability and eliminates a common anti-pattern in unit testing: “tests that run, but test nothing.”
Summary #
Fossil Test’s assumption system is designed to elevate expectations for test quality:
- Forces explicit validation.
- Prevents empty tests.
- Provides structured, typed checks.
- Enables cross-checking and anomaly reporting.
- Encourages test literacy across teams.
In Fossil Test, every test must make meaningful assumptions—or it isn’t a test at all.
