ResourceTimeSourceTestSuite: Rework to be more in-line with newer tests #342

Activity

1. YYDan

   self-assigned this

   on Aug 20, 2026
2. YYDan

   added

   refactorAn improvement to existing test/module codeAn improvement to existing test/module code

   on Aug 20, 2026
3. YYDan

   added the

   Task

   issue type on Aug 20, 2026
4. YYDan

   added a commit that references this issue on Oct 2, 2026

   Fixes #342 - Rework ResourceTimeSourceTestSuite into one test per sce…

   ...

   This issue will close once commit 4ff13a3 is merged into the 'develop' branch.

   4ff13a3
5. YYDan commented on Oct 2, 2026

   

   YYDan

   on Oct 2, 2026

   Last edited by YYDan

   ContributorAuthor

   More actions

   Reworked ResourceTimeSourceTestSuite to report one pass/fail per scenario, in line with the newer test suites.

   Structure: 9 tests (5 sync facts + 4 async) -> 34 tests (30 sync facts + 4 async), 39 asserts unchanged. Added two section headers separating the synchronous and async groups.

   Synchronous facts - split per assert, named <original_name> #N:

   Original fact	Asserts	Split into
   Time Sources: Constant Values	10	10 facts, one per constant
   Time Sources: Existence	11	11 facts, one per check
   Time Sources: State Transitions	1	left as 1 fact - it's a single fuzzed state-machine property check with one assert call-site, so there's nothing to split
   Time Sources: Parents and Children	3	3 facts, one per property checked (parent, children count, children data), each over its own freshly generated tree
   Time Sources: Reconfiguration	5	5 facts, one per property checked across the 1000-iteration reconfigure loop

   For Existence #8-#11 (the parent/child destruction-safety checks), the scenario is a genuinely sequential narrative - a time source handle can't be seeded directly to a given state the way a scalar can, it has to be legitimately created/destroyed via the real API. Each of those four facts therefore replays only the minimal setup needed to reach its own precondition, rather than chaining off a previous fact's leftover state.

   Async tests - reviewed individually, all four left intact, per the issue's own caution that splitting a multi-frame async test into N tests multiplies suite wall-clock time:

   • Expiry Frames: batches 10 randomly-configured sources through one frame-stepping loop specifically to amortise the async wall-clock cost across many scenarios at once. Splitting into 10 tests would multiply the async runtime for no extra coverage, since they already run concurrently within the same frame counter.
   • Self Destruction: a single coherent scenario - a source destroying itself inside its own callback, checked for visibility/timing at a few checkpoints of the same run. Not decomposable without re-running the whole async progression for each checkpoint.
   • Sibling Destruction: inherently a population-scale interaction test (100 siblings mutating a shared array while iterating). Splitting into per-sibling tests would lose the exact race/mutation-safety property under test.
   • Time delta propagation: already a single, minimal scenario (one global-parented callback creating one game-parented source, checking frame-delta ordering). Nothing to split.

   Moved all four under an // ASYNC TESTS section header with a short comment recording this reasoning in the source, so it is not re-litigated on the next pass.

   Assert description fixes: tightened two duplicate/ambiguous assert messages in Self Destruction (both previously read "Time source still appears to exist after its self-destruction") to identify which specific checkpoint failed - immediately after time_source_destroy() inside the callback, versus on the following frame.

   Verified:

   • Test count: 34 (30 facts + 4 async tests)
   • Assert count: 39, unchanged from before the rework
   • No duplicate test names
   • GML-aware bracket/paren/brace balance: clean
   • Normalised assert-content diff against the pre-rework file: only the two message edits above - every other tested value and the untouched helper functions/async bodies are byte-identical to before
   • Full suite run on both VM and YYC: all 34 tests pass, wall-clock time not regressed (all four async tests were left untouched, so their per-test timeout/duration is unchanged)

   VM.txt

   YYC.txt
6. YYDan

   linked a pull request that will close this issueFixes #342 - Rework ResourceTimeSourceTestSuite into one test per scenario #361on Oct 2, 2026