Testing
Writing, fixing and strengthening automated tests.
Download all 33
Entries
Search and filter in Testing- Review test quality
Reviews a test suite or diff for weak assertions, over-mocking, hidden coupling, sleeps, nondeterminism and tests that cannot fail, with a concrete rewrite for each problem. Use when reviewing tests.
- Test-writing rules
Standing rules for tests an assistant writes, covering behaviour over implementation, no sleeps, deterministic data, mocks only at boundaries and one reason to fail per test.
- Write a test plan
Writes a risk-based test plan for a feature or release covering scope, risks, test levels, environments, data, manual checks automation misses and exit criteria. Use before testing a release.
- Add characterization tests to legacy code
Pins down what untested legacy code does today with characterization and golden-master tests, bugs included, so it can be changed safely. Use before refactoring or modifying code with no tests.
- Add a regression test for a bug
Writes the smallest test that fails on the buggy code and passes with the fix, and proves both by running it. Use after fixing a bug, or before fixing one, so it cannot return.
- Build a fake for an external API
Builds a test double for a third-party API, choosing an in-memory fake, stub server or record-and-replay, with contract checks against the real API and error, timeout and rate-limit cases.
- Exploratory tester
Acts as a curious, sceptical exploratory tester who hunts bugs automation misses with tours, heuristics and oracles, and writes bug reports developers can reproduce. Use as a testing partner.
- Find and fill the riskiest test gaps
Finds untested behaviour that matters most, ranked by risk rather than coverage percentage, and writes tests for the top gaps. Use when a module feels under-tested or before a risky change.
- Fix a red test suite after an upgrade or merge
Takes a red test suite back to green in gated steps, clustering failures, proving each root cause and fixing code or outdated tests with evidence. Use after an upgrade or merge breaks many tests.
- Fix a flaky test
Finds why a test passes and fails intermittently and fixes the cause instead of adding retries. Use when a test fails only sometimes, locally or in CI.
- Generate API tests from a spec
Generates API tests from an OpenAPI or GraphQL schema with positive, boundary, invalid-input, auth and permission cases, response schema checks and property-based fuzzing where tools allow.
- Plan a device and browser test matrix
Chooses which devices, OS versions, browsers and screen sizes to test from usage analytics and risk, split into must-test, sampled and emulator-only tiers. Use before a release cycle.
- Refactor tests for clarity without losing coverage
Cleans up a test file or suite, fixing unclear names, duplicated setup, over-mocking and assertions on internals, while proving with coverage and mutation checks that nothing stopped being tested.
- Run mutation testing on a module
Sets up mutation testing for one module, triages the surviving mutants and writes tests that kill the ones that matter. Use when coverage looks high but you doubt the tests would catch a real bug.
- Speed up a slow test suite
Cuts test suite runtime from timing reports and setup code by fixing slow fixtures, sleeps, database resets and isolation-safe parallelism. Use when the tests themselves, not the CI config, are slow.
- Test an app under bad network conditions
Designs and automates tests for slow, lossy, captive-portal and offline networks, covering timeouts, retries, offline queues, duplicate submissions and what users see in each state.
- Raise meaningful test coverage across a codebase
Raises test coverage where it reduces risk, measuring first, writing behaviour tests for risky untested code and checking them with sampled mutation testing. Use for a coverage push that must count.
- Test engineer
Designs and writes tests that catch real regressions, chooses the cheapest test level that proves a behaviour, and refuses flaky or assertion-free tests. Use as a testing persona or subagent.
- Test firmware off target
Sets up host-based unit tests for firmware by separating logic from the HAL, faking registers and peripherals, and running in CI. Use when firmware has no automated tests.
- Test game mechanics deterministically
Makes game logic testable with a fixed timestep, seeded randomness and input replays, then writes tests for combat, physics and progression rules. Use when only manual playtests catch regressions.
- Unit test data transformations
Writes small-fixture unit tests for SQL, dbt, pandas or Spark transformations with hand-built rows for nulls, duplicates, late records and boundaries that run in seconds in CI.
- Write consumer-driven contract tests
Writes consumer-driven contract tests between two services and the CI gate that runs them, so a breaking API change fails before deploy. Use when services that call each other ship independently.
- Write a resilient end-to-end test
Writes an end-to-end browser test for a user flow with role-based locators, auto-waiting assertions and isolated test data, never fixed sleeps. Use when adding UI coverage for a critical path.
- Write exploratory test charters
Writes session-based exploratory testing charters for a feature with time boxes, heuristics, a session sheet and a debrief agenda, aimed at risks automation misses. Use before a release.
- Write a fuzz harness
Writes a coverage-guided fuzz harness for a parser or decoder with a seed corpus, dictionary, sanitizers, a CI time budget and crash triage. Use for code that reads untrusted input.
- Write Gherkin scenarios
Turns acceptance criteria into declarative Given/When/Then scenarios with one behaviour each, scenario outlines for data variants and business language that survives UI changes. Use in BDD teams.
- Write integration tests with real dependencies
Writes integration tests that run against real dependencies such as databases and queues in containers, with fixtures, isolation between tests and cleanup. Use when mocks hide bugs at the boundary.
- Write manual test cases
Writes manual test cases a non-developer can run, with preconditions, numbered steps, test data, expected results and priority, grouped into smoke and full passes. Use for UAT or before automation.
- Write native mobile UI tests
Writes UI tests for an iOS, Android, React Native or Flutter screen with stable identifiers, condition waits instead of sleeps, seeded launch state, network stubs and screen objects.
- Write property-based tests
Finds the invariants a function must keep and writes property-based tests with generators that shrink well. Use when example-based tests miss edge cases in parsers, encoders or pure logic.
- Write test data factories
Writes test data builders or factories that produce valid objects by default and take short, readable overrides. Use when tests are full of copy-pasted fixtures that break on every model change.
- Write unit tests
Writes unit tests that pin a unit's behaviour, covering boundaries, errors and edge inputs in the project's own test style, and proves each test can fail. Use for new or untested code.
- Write visual regression tests
Writes visual regression tests for UI components with deterministic snapshots, tight diff thresholds, a state matrix and CI setup. Use when CSS changes keep breaking screens nobody rechecked.
Not: reviewing a change (code-review); load testing (performance).