Skip to content

🧪 RevFramework Crafting — Testing Philosophy

This document explains how the Crafting system is tested, what the tests are designed to protect, and what they intentionally do not claim.

This is not marketing material.

It is an engineering-facing overview of the testing philosophy behind the Crafting system.

🎯 The Goal of the Tests

The Crafting tests exist to protect:

  • behavioural guarantees
  • regression safety
  • deterministic framework behaviour
  • explicit lifecycle semantics
  • edge-case handling

The tests are designed to answer questions like:

  • “Does this behaviour still work after refactors?”
  • “Did a hidden assumption accidentally change?”
  • “Will this failure path still compensate correctly?”
  • “Does restore/reconciliation still behave consistently?”

The goal is predictability, not “perfect software.”

🔒 Hostile Consumer Tests

Most Crafting tests are written as Hostile Consumer tests.

This means the tests interact with the system exactly the way a real project would:

  • through public APIs
  • through supported interfaces
  • through supported adapters and seams
  • without reflection
  • without private-field access
  • without editor hacks

These tests intentionally avoid depending on implementation details.

If a Hostile test passes, the public API contract is behaving correctly.

⚙️ InternalTruth Tests

The Crafting system also contains a smaller set of InternalTruth tests.

These tests validate internal framework assumptions that are important for long-term stability but are not part of the supported public API.

Examples include:

  • scheduler normalization behaviour
  • restore ordering
  • cache behaviour
  • reservation idempotency
  • routing fallback semantics
  • offline reconciliation assumptions

InternalTruth tests are intentionally separated from Hostile tests.

They exist to protect framework integrity during future refactors.

🧩 What the Crafting Tests Validate

The current Crafting test suite validates behaviour including:

Preflight & Validation

  • Input / currency / space preflight ordering
  • Validator override behaviour
  • Rejection semantics
  • Probe consistency

Authority

  • Mutation gating
  • Scheduler-control authority
  • Denied operations
  • No unauthorized state changes

Job Lifecycle

  • Queued → Running → Completed flow
  • Failure flow
  • Cancellation flow
  • Pause / resume behaviour
  • Remaining-time freezing
  • Queue promotion behaviour

Scheduler Behaviour

  • Global concurrency caps
  • Per-station concurrency caps
  • Queue fairness
  • Promotion ordering
  • Station normalization

Routing

  • Routed-container space checks
  • Router fallback behaviour
  • Router exception isolation
  • Default-container fallback semantics

Refund & Compensation Paths

  • Currency refunds
  • Input refund policies
  • Delivery-time failures
  • Immediate-delivery failures
  • Best-effort compensation behaviour

Persistence & Offline Progress

  • Snapshot restoration
  • Offline completion
  • Missing snapshot data
  • Paused-job restore behaviour
  • Restore-time reconciliation

Escrow / Strong Crafting Path

  • Reservation flows
  • Hold / capture / release behaviour
  • Reservation idempotency
  • Reservation cleanup safety
  • Strong-path staged failures
  • Honest partial-mutation behaviour when adapter contracts fail

Modifiers & Validators

  • Modifier application
  • Currency scaling
  • Output scaling
  • Validator blocking behaviour
  • Station-aware behaviour

🧠 Deterministic Test Infrastructure

The Crafting tests use deterministic fake adapters and providers including:

  • Inventory adapters
  • Currency adapters
  • Escrow reservation adapters
  • Time providers

These fakes are intentionally strict and explicit.

They support:

  • fail-next toggles
  • deterministic staged failures
  • ordering assertions
  • repeatable restore scenarios
  • edge-case simulation

This allows difficult lifecycle and compensation paths to be tested reliably.

❌ What These Tests Do NOT Claim

The tests do not claim:

  • the framework is bug-free
  • all gameplay combinations are covered
  • multiplayer correctness is guaranteed
  • third-party adapters are validated
  • all external integrations are safe
  • performance/stress limits are proven

The tests validate framework behaviour and guarantees — not every possible project implementation.

🧩 The Philosophy

RevFramework systems are designed around:

  • explicit guarantees
  • predictable behaviour
  • transparent failure handling
  • modular integration seams

The tests exist to lock those guarantees down over time as the framework evolves.

The goal is not to hide complexity.

The goal is to make framework behaviour understandable, stable, and intentional.

TL;DR

The Crafting tests are designed to protect guarantees, not pretend software can never fail.

Hostile tests validate supported public behaviour.

InternalTruth tests protect hidden framework assumptions.

Together, they help keep Crafting predictable as RevFramework evolves.