← Back to Go desktop foundation team
See how it helps
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
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.
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