agentsclimarketplace

Testing strategy

Skill Amey-Thakur/AI-SKILLS/skills/testing/testing-strategy

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill testing-strategy

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Decide what to test, at which level, and what to skip, so tests catch real regressions without freezing the design. Use when writing tests or planning coverage for a change.

SKILL.md

2.4 KB, 522 tokens by cl100k_base, as published. Nobody here has run it

Testing strategy

Tests exist to let you change code without fear. A suite that blocks refactoring or passes while the product is broken has failed at its one job.

Method

  1. Test behavior, not implementation. Assert what the caller observes , return values, emitted events, stored rows, rendered text: never private internals or call sequences. The test that breaks on a faithful refactor is a bug in the test.
  2. Spend tests where the risk is. Rank the change's code paths by (likelihood of being wrong) × (cost when wrong), and test from the top. Parsing, money, permissions, concurrency, and anything with an off-by-one opportunity outrank getters forever.
  3. Choose the cheapest level that catches the failure:
    • Unit for pure logic and edge-case matrices: milliseconds, no mocks needed when the logic is genuinely pure.
    • Integration for the seams: real database, real serialization, real filesystem. Most production bugs live at seams; a mock at every seam tests your assumptions about a dependency, not the dependency.
    • End-to-end for the handful of flows whose breakage is an incident: keep them few, stable, and ruthlessly maintained.
  4. Name the case, cover the edges. A good test name states the rule: rejects_expired_token, merges_consecutive_same_role_turns. For every happy path, ask: empty input, one item, maximum size, duplicate, wrong type, failure of the dependency. Each answered with a test or a written reason it cannot happen.
  5. One behavior per test. Shared setup is fine; shared assertions are not. When test_everything fails, nobody knows what broke.
  6. A regression gets a test that fails without the fix: before or with the fix, never "later". It is the only test guaranteed to be about a real bug.

What not to test

Framework behavior, language features, third-party libraries, trivial delegation, and anything a type checker already proves. Deleting a worthless test is a contribution.

Litmus tests

  • Would this suite catch the last three real bugs this area had?
  • Can you rename every private function without touching a test?
  • Does the suite run fast enough that people run it before pushing, not instead of pushing?

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.