AgentStack
SKILL verified MIT Self-run

Testing

skill-sefaertunc-worclaude-testing · by sefaertunc

Test philosophy, coverage strategy, test-first patterns, what to test and what not to

No reviews yet
0 installs
16 views
0.0% view→install

Install

$ agentstack add skill-sefaertunc-worclaude-testing

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Are you the author of Testing? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Testing

What to Test

Test behavior, not implementation. A test should verify what a function does, not how it does it. If you refactor the internals and the test breaks, the test was testing the wrong thing.

Good test: "given a valid email, returns true" Bad test: "calls regex.match with pattern /^[a-z].../"

Meaningful Coverage vs Line Coverage

100% line coverage is a vanity metric. You can have 100% coverage and still ship bugs if your tests don't exercise meaningful paths.

Focus coverage on:

  • Business logic (the rules that make your app unique)
  • Error handling paths (what happens when things go wrong)
  • Boundary conditions (empty, null, max values, off-by-one)
  • Integration points (where your code meets external systems)

Skip coverage on:

  • Simple getters/setters
  • Framework boilerplate
  • Generated code
  • Pure delegation (functions that just call another function)

Edge Cases Worth Testing

Every function has these potential edge cases. Consider which apply:

  • Null / undefined / empty string
  • Empty array / empty object
  • Single element
  • Very large input
  • Negative numbers / zero
  • Unicode and special characters
  • Concurrent access
  • Network timeout / failure

You don't need to test ALL of these for every function. Think about which ones are realistic for your specific case.

Test-First Workflow

Writing tests first helps when:

  • The behavior is well-defined but the implementation isn't clear
  • You're fixing a bug (write the failing test first, then fix)
  • You're implementing a spec (tests become the spec's executable form)

Test-first hurts when:

  • You're exploring and don't know what the API should look like
  • You're prototyping and will throw the code away
  • The test would be trivial (testing that a constant equals itself)

When doing test-first: write the test, watch it fail, implement the minimum to pass, then refactor. Don't write all the tests up front — go one at a time.

Test Structure

Follow Arrange-Act-Assert (AAA):

// Arrange: set up the test conditions
const input = createValidInput();

// Act: call the thing being tested
const result = processInput(input);

// Assert: verify the outcome
expect(result.status).toBe('success');

Keep tests independent. No test should depend on another test running first. No shared mutable state between tests.

Naming Tests

Test names should read like specifications:

  • "should return 401 when token is expired"
  • "should merge arrays without duplicates"
  • "should create backup directory if it doesn't exist"

Not:

  • "test1"
  • "it works"
  • "handles edge case"

Testing Anti-Patterns

  • Snapshot abuse: snapshots test that output didn't change, not that it's correct.

Use sparingly and review snapshot diffs carefully.

  • Mock everything: if your test mocks 5 dependencies, you're testing the mocking

framework, not your code. Prefer integration tests for heavily-connected code.

  • Test the framework: don't test that Express routes requests or that React renders

components. Trust the framework; test YOUR logic.

  • Brittle assertions: asserting on exact error messages or full object shapes when

only one field matters. Assert on what matters.

  • Slow tests without reason: if a test takes seconds, it's probably doing I/O

that should be mocked or it's an integration test that should be tagged separately.

Gotchas

  • Flaky tests are worse than no tests. They erode trust in the entire suite.

Fix immediately or quarantine with a clear TODO.

  • Test data should be self-contained. Don't rely on database state, external

services, or file system artifacts from other tests.

  • When a test fails, the test might be wrong. Don't assume the code is broken —

read the test carefully first.

  • Delete tests that test deleted features. Orphan tests confuse and mislead.
  • Async tests need proper awaiting. An unawaited assertion silently passes.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.