Skip to content

🧪 RevFramework Health — Testing Philosophy

This document explains how the Health 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 Health system.

🎯 The Goal of the Tests

The Health tests exist to protect:

  • behavioural guarantees
  • regression safety
  • deterministic framework behaviour
  • explicit lifecycle semantics
  • edge-case handling
  • supported public extension seams
  • runtime event and mutation ordering

The tests are designed to answer questions like:

  • “Does this behaviour still work after refactors?”
  • “Did a hidden assumption accidentally change?”
  • “Does this lifecycle transition still fire the right events?”
  • “Does this rejection path leave state untouched?”
  • “Does this preview result match the real mutation path?”
  • “Does this before-death or revive hook still behave consistently?”

The goal is predictability, not “perfect software.”

🔒 Hostile Consumer Tests

Most Health tests are written as Hostile Consumer tests.

This means the tests interact with the system the way a real project or advanced user would:

  • through public APIs
  • through supported interfaces
  • through supported components
  • through supported adapters and seams
  • without relying on private implementation details
  • without assuming unsupported mutation patterns

These tests intentionally avoid treating internal implementation as a user-facing contract.

If a Hostile test passes, the supported public behaviour is behaving correctly.

Examples include:

  • damage and healing through public APIs
  • shield interaction through supported shield seams
  • rule hubs and rule components
  • authority denial behaviour
  • before-death interception
  • revive/death lifecycle behaviour
  • snapshot capture and restore behaviour
  • UI connector behaviour
  • event listener exception isolation

⚙️ InternalTruth Tests

The Health system also contains InternalTruth tests.

These tests validate framework assumptions that are important for long-term stability, even when those assumptions are not the primary user-facing learning surface.

Examples include:

  • damage event ordering
  • death event ordering
  • revive event ordering
  • mutation-vs-event timing
  • preview rule and shield ordering
  • authority bypass/restore semantics
  • silent restore semantics
  • snapshot authority behaviour
  • regen interruption semantics
  • internal runtime guarantees around death and revive transitions

InternalTruth tests are intentionally separated from Hostile tests.

They exist to protect framework integrity during future refactors.

🧩 What the Health Tests Validate

The current Health test suite validates behaviour including:

Damage

  • Basic damage application
  • zero / negative damage rejection
  • dead-target rejection
  • invincibility rejection
  • damage-lock rejection
  • shield absorption
  • partial shield leakage
  • true-damage / shield-bypass behaviour
  • final applied damage clamping
  • percent-based damage
  • multiplier and flat-delta handling
  • damage attempted reporting

Healing

  • basic healing
  • healing clamped to max health
  • zero / negative healing rejection
  • dead-target healing rejection
  • overheal spill behaviour
  • healing modifiers
  • heal rules
  • preview healing
  • healing event behaviour
  • listener exception isolation

Shields

  • explicit shield provider selection
  • local shield resolution
  • shield-chain behaviour
  • full absorption
  • partial absorption
  • shield bypass
  • shield preview behaviour
  • shield ordering relative to damage rules

Rules

  • armour / reduction behaviour
  • team / friendly-fire behaviour
  • affinity scaling
  • execute-threshold behaviour
  • damage clamp behaviour
  • damage reflection
  • lifesteal
  • attacker damage modifiers
  • heal blocking
  • heal scaling
  • low-health heal boosting
  • rule bypass flags
  • post-damage and post-heal hooks

Authority

  • mutation gating
  • denied damage
  • denied healing
  • denied kill
  • denied revive
  • denied current/max mutation
  • injected authority resolver behaviour
  • resolver clearing / fallback behaviour
  • authority-denied event behaviour
  • last authority error state
  • successful mutation clearing previous authority errors

Lifecycle

  • kill behaviour
  • death finalization
  • duplicate death prevention
  • revive behaviour
  • revive no-op behaviour while already alive
  • death cancellation through before-death handlers
  • extra-life / totem interception
  • kill-command interception rules
  • revive side effects
  • invincibility reset or activation on revive
  • regen cooldown reset on revive

Event Ordering

The Health tests explicitly protect event ordering because event order is part of the practical runtime contract.

Validated ordering includes:

  • damage applied events
  • detailed damage events
  • health changed events
  • damage attempted events
  • death events
  • revive events
  • no-event silent mutations
  • listener state visibility at the moment events fire

This matters because game code often reacts to Health events for UI, VFX, audio, death handling, AI, rewards, and save-state logic.

Preview Behaviour

Health previews are tested separately from mutation behaviour.

The test suite validates that previews:

  • do not mutate health
  • do not mutate shields
  • apply rules when requested
  • can ignore rules when requested
  • include shield preview when supported
  • can ignore shields when requested
  • clamp to current health
  • return zero when dead
  • expose detailed after-rules and after-shields values

Preview tests protect the difference between:

  • “what would happen?”
  • and
  • “what actually happened?”

Snapshot & Restore

Snapshot tests validate:

  • current / max / dead-state capture
  • silent restore behaviour
  • dead-state restoration
  • clamping on invalid snapshot values
  • restore behaviour that does not emit gameplay events
  • authority-independent snapshot restore
  • clearing or preserving runtime report state only when the relevant lifecycle operation actually runs

Snapshots are tested as state restoration, not as gameplay damage/heal operations.

Regeneration

Regeneration tests validate:

  • delayed regen start
  • repeated healing ticks
  • stopping at full health
  • disabled regen behaviour
  • damage interrupting active regen
  • cooldown restart behaviour
  • smooth regen behaviour
  • regen event emission
  • ceiling-limited regen
  • no regen while dead

These tests protect regen as a lifecycle-adjacent system, not just as a timer that adds health.

UI Connectors

Health UI connector tests validate:

  • fill amount updates from health percent
  • manual refresh behaviour
  • no-target fallback behaviour
  • world-space health bar updates
  • hide-when-full behaviour
  • gradient colour evaluation
  • connector safety around missing targets

These tests exist because UI connectors are part of the supported Health integration surface.

🧠 Deterministic Test Infrastructure

The Health tests use focused test doubles and controlled Unity objects including:

  • fake / recording rule components
  • throwing event listeners
  • custom shield implementations
  • controlled invincibility handlers
  • recording before-death handlers
  • recording regen hooks
  • direct GameObject-based public API setups
  • deterministic component composition

These fakes are intentionally strict and explicit.

They support:

  • event ordering assertions
  • exception isolation checks
  • rule cancellation checks
  • before-death interception checks
  • state mutation assertions
  • public-seam validation
  • repeatable lifecycle scenarios

This allows difficult runtime semantics 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
  • all third-party integrations are validated
  • every custom shield/rule implementation is correct
  • multiplayer correctness is guaranteed
  • project-specific revive/death policies are validated
  • every possible UI presentation is covered
  • performance/stress limits are fully proven

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

🧩 The Philosophy

RevFramework Health is designed around:

  • explicit lifecycle semantics
  • predictable mutation behaviour
  • transparent rejection reasons
  • supported extension seams
  • safe event notification
  • public API usage
  • clear preview-vs-runtime separation
  • intentional death and revive behaviour

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 Health behaviour understandable, stable, and intentional.

TL;DR

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

Hostile tests validate supported public behaviour.

InternalTruth tests protect runtime semantics and framework assumptions.

Together, they help keep Health predictable as RevFramework evolves.