Testing and reliability

Builds reliable checks around gameplay rules and regression fixes. Controls time, randomness and external services so a failing test identifies behavior rather than accidental test conditions.

testing-discipline

Agents using this skill

See how it helps

When is it useful?

Use this skill when you add behavior, fix a bug or need reliable evidence that a change works. It follows the project’s existing test framework and focuses on observable behavior and relevant failure cases.

What does it help you do?

Reproduces a reported bug with a failing test before changing the implementation.
Covers affected edge cases and keeps tests independent of real time, random values and external services.
Runs the relevant checks and reports actual results, including failures or checks that could not run.

Try asking this

Fix a bug where a timed power-up remains active after respawn. First reproduce it with a failing test using a controlled clock. Cover expiry, death and repeated pickup, then correct the implementation and rerun the focused checks. Report actual results and any engine-runtime scenario that still needs manual verification.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Testing Discipline

Find the existing setup

Locate the test runner, its config and existing tests before writing any (package.json scripts, phpunit.xml, pytest.ini, Makefile, CI workflow).
Use the repo's framework, file layout, naming and helpers. Do not introduce a second test framework.
Learn the exact command CI runs and use it.

Write or update tests

Every behavior change gets a test: new behavior is covered, changed behavior has its tests updated to the new expectation.
Test observable behavior through public interfaces, not private internals.
Cover the edge cases the change touches: empty, null, boundaries, error paths, permissions.
One behavior per test, with a name that says what it proves.
A pure refactor keeps existing tests green without editing their assertions. If an assertion must change, the behavior changed: say so.

Bugs: reproduce first

Write a test that fails for the reported bug before fixing it. Run it and confirm it fails for the right reason.
Fix the code, then see the same test pass.
If the bug cannot be reproduced in a test, say so and explain how you verified the fix instead.

Keep tests deterministic

No dependence on wall clock, timezone, locale, randomness, network, test order or shared global state. Freeze or inject time, seed randomness, stub external services.
No arbitrary sleeps; wait for a condition or use fake timers.
Each test creates and cleans up its own data (temp dirs, transactions, fresh databases).
A flaky test is a bug: fix the cause, do not retry until green.

Never fake green

Do not skip, delete, comment out, mark as expected-failure or loosen a test to make the suite pass.
Do not weaken assertions (truthy instead of an exact value) or update snapshots blindly. Review every snapshot diff.
Do not mock the unit under test.
If a test fails for reasons unrelated to your task, leave it as is and report it with the error.

Run and report

Run the tests you wrote, then the relevant wider suite; run the full suite when it is reasonably fast.
Report the real result: the command, pass/fail counts and failures verbatim. Never claim tests pass without running them in this session.
If tests cannot run (missing service, credentials, tooling), say exactly that and what remains unverified.

Before you finish

Every behavior change has a new or updated test.
Bug fixes have a test that failed before the fix and passes after it.
Tests ran in this session with the repo's own command; results reported as observed.
No skipped, deleted or weakened tests.
New tests are deterministic and independent of each other.

Included files 1

SKILL.md