Skill · Version 1.0.0

Testing and reliability

Builds tests for individual functions and complete workflows, helping catch errors and prevent previously fixed problems from returning.

testing-discipline

Team members 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

Add a regression test for a learner receiving two certificates after a retry. Reproduce the failure, fix the cause and run the relevant existing tests. Replay the same completion event after a simulated interruption. Assert one certificate identity and preserve the failing-before, passing-after evidence for the actual bug.

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