Testing
AuraScore 79/100

Numerical Invariant Property Test Harness Generator

Generate property-based automated testing scripts to validate numerical algorithms against precision drift, overflow, and mathematical invariants.

Use this template when validating scientific computing routines, numerical simulations, or linear algebra implementations. It generates executable property-based test suites that stress floating-point edge cases and mathematical identities.

Template

Role: Principal Scientific Computing Quality Engineer specializing in numerical stability and formal invariant testing.

Context

  • Target Algorithm Implementation: {{target_algorithm_code}}
  • Core Mathematical Invariants: {{mathematical_properties}}
  • Absolute and Relative Tolerances: {{precision_tolerance_threshold}}
  • Input Domain and Boundary Conditions: {{input_domain_bounds}}
  • Property Test Framework: {{target_test_framework}}
  • Extreme Distribution Shapes: {{edge_case_distributions}}

Task

Synthesize a complete, executable property-based testing script that mathematically verifies {{target_algorithm_code}} across degenerate, edge, and randomized high-entropy input distributions using {{target_test_framework}}.

Method

  1. Analyze {{target_algorithm_code}} to identify arithmetic operations susceptible to catastrophic cancellation, floating-point underflow, overflow, and subnormal representation.
  2. Translate {{mathematical_properties}} into strict algebraic invariants (e.g., idempotence, commutativity, symmetry, triangular inequality, conservation laws).
  3. Formulate custom input strategy generators parameterized by {{input_domain_bounds}} and {{edge_case_distributions}} targeting branch boundaries, infinities, signed zeros, and NaN boundaries.
  4. Design parameterized test assertions enforcing dual relative (rtol) and absolute (atol) tolerances specified in {{precision_tolerance_threshold}}.
  5. Implement invariant metamorphic test functions comparing baseline algorithmic steps with mathematically equivalent perturbed formulations.
  6. Incorporate automated shrinking heuristics and failure triage reporting to isolate minimal counterexamples for ill-conditioned inputs.
  7. Add benchmark performance harnesses measuring floating-point operation overhead and timing variance across test runs.

Constraints

  • MUST write 100% executable test scripts compatible with {{target_test_framework}} without unreferenced pseudocode.
  • MUST explicitly assert mathematical invariants rather than simple regression snapshot comparisons.
  • MUST NOT suppress floating-point runtime warnings (e.g., ZeroDivisionError, RuntimeWarning, invalid value) without explicit exception assertions.
  • Include explicit type annotations and docstrings defining mathematical theorem justifications for every test case.

Output format

Provide the complete test script structured in the following sequential order:

  1. Dependency Imports and Mathematical Constants Setup
  2. Custom Input Strategies and Distribution Generators
  3. Invariant Property Test Suite (minimum 5 distinct property tests)
  4. Metamorphic and Perturbation Stability Test Suite
  5. Test Execution Entrypoint with Detailed Error Diagnostics

Self-review

  • Verify that all mathematical invariants from {{mathematical_properties}} have dedicated, executable test functions.
  • Ensure tolerance comparisons strictly utilize {{precision_tolerance_threshold}} without hardcoded magic floats.
  • Confirm input generators cover all specified boundary edges from {{input_domain_bounds}} and {{edge_case_distributions}}.
AuraScore breakdown
79/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-testing
complex-reasoning-analysis-math
python
numerical-analysis
property-testing