Skip to content

Property-based invariants: stream balance and escrow never negative #136

@greatest0fallt1me

Description

@greatest0fallt1me

Property tests for invariants: non-negative balance and conservation of value

    ## Description

    Add **property** tests (e.g. fast-check, gopter, or QuickCheck) that randomize a

sequence of valid mutating events on a stream and assert invariants:
balances never negative; sum of legs matches on-chain mock; settle cannot
over-release escrow. Complements unit tests for a Soroban-backed system.

    ## Requirements and context

    - **Model** a simplified in-memory Stellar/escrow mock for speed.
  • Seed-deterministic randomness for CI stability.

  • Invariants listed in a single module as pure functions; reused in prod code path where possible.

  • Failing cases shrink to minimal repro; commit as regression test.

  • Time budget in CI; skip heavy mode on PR, run nightly.

      ## Suggested execution
    
      1. `git checkout -b test/property-invariants-balance`
    
  1. Wire fast-check in JS or equivalent in your stack.

  2. PR with 1–2 minimal shrunk failures turned into static tests.

  3. Security note: invariants are not a substitute for on-chain security.

  4. Link to any formal verification future work in contracts repo.

     ## Test and commit
    
  • Run the full test suite; add or update tests until the agreed coverage bar is met.
  • Cover edge cases listed in this issue; document any intentional exclusions with brief rationale in the PR.
  • Include relevant test output (e.g. test runner summary) or a link to a passing CI run in the pull request.
  • Add security notes for auth, keys, PII, chain settlement, or money movement (assumptions verified, out-of-scope items).

Example commit message

test(streams): property-based invariants for balances and escrow conservation

Guidelines

  • Target: at least 95% coverage on new or meaningfully changed code (per the repo’s standard tooling).
  • Documentation: update contributor-facing or API documentation where a reviewer would be blocked without it.
  • Timeframe: 96 hours to ready-for-review (surface blockers early).

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-settlementStreamPay ghit: area-settlementdomain-qualityStreamPay ghit: domain-qualitypriority-p2StreamPay ghit: priority-p2type-testingStreamPay ghit: type-testing

    Type

    No fields configured for Task.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions