agentleFS
Sign inStart free
andr-caandr-ca/agentharness/.claude/skills/testing/SKILL.md

testing

Skill1 starsChanged 2 months agoMITView on GitHub

Use when writing tests, deciding on test coverage, choosing between unit/integration/E2E tests, applying TDD, or reviewing test quality — covers rigor tiers, the Red-Green-Refactor cycle, coverage requirements, and Playwright for UI testing.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 172 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check .agentharness-profile or .github/CODING_GUIDELINES.md for the project's tier before assuming 80% applies.

    line 26
  2. Distinctive:

    Never skip Red — a test that never fails doesn't prove anything.

    line 36
  3. Distinctive:

    Prefer specific assertions that produce readable failure messages:

    line 94

“Common” is measured: kept by at least 6 in 10 of the 172 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Testing

This skill is self-contained for day-to-day use. Deeper reference (needs the full harness checkout): patterns/testing/TDD.md (full TDD workflow), patterns/testing/COVERAGE_REQUIREMENTS.md (80% rule and pragma), patterns/testing/PLAYWRIGHT_UI_TESTING.md (E2E screenshots), patterns/testing/COMPLETION_CHECKLIST.md.

Rigor tiers — apply the right standard, not the maximum

TierCoverageTDDNotes
Production≥ 80% line+branchRequiredLibraries, agents, shipped services
InternalMust have testsRecommendedNo numeric floor; cover what's expensive to get wrong
PrototypeNone requiredOptionalSkip freely; document the decision

Check .agentharness-profile or .github/CODING_GUIDELINES.md for the project's tier before assuming 80% applies.

Red-Green-Refactor

  1. Red — write a failing test for the one behavior you're adding.
  2. Green — write the minimum code to make it pass (not the final code — the correct code comes in the next step).
  3. Refactor — clean up duplication and naming while tests stay green.

Never skip Red — a test that never fails doesn't prove anything.

Test one behavior per test

# WRONG: five assertions for one behavior — one failure hides the rest
def test_user_creation():
    user = User.create(email="a@b.com", password="s3cr3t")
    assert user.id is not None
    assert user.email == "a@b.com"
    assert user.password_hash is not None
    assert user.created_at is not None
    assert user.is_active is True

# RIGHT: one assertion covers "all fields are set" as a single behavior
def test_user_creation_populates_all_fields():
    user = User.create(email="a@b.com", password="s3cr3t")
    assert user == {
        "id": AnyString(),
        "email": "a@b.com",
        "password_hash": AnyString(),
        "created_at": AnyDatetime(),
        "is_active": True,
    }

Split into multiple tests only when the behaviors can independently fail for unrelated reasons.

Test pyramid shape (guide, not hard rule)

~70% unit · ~25% integration · ~5% E2E. Bias toward cheap-to-run unit tests; don't duplicate unit coverage with integration tests that only exist for the coverage number.

Coverage floor: 80% line + branch at Production tier

# pragma: no cover is for truly unreachable code — not for skipping inconvenient tests
if sys.version_info >= (3, 12):
    new_behavior()
else:  # pragma: no cover — never reached on supported versions
    old_behavior()

Measure coverage before marking work complete. Don't approve a PR that claims ≥ 80% without a CI report to confirm it.

UI testing (Playwright)

For UI tests: screenshot-review every visual path at least once (not just "it didn't crash"). State in the PR description which flows you verified visually — CI can check that the test ran, but not that the UI looked correct. See patterns/testing/PLAYWRIGHT_UI_TESTING.md for full conventions.

Assertion style

Prefer specific assertions that produce readable failure messages:

// POOR: tells you nothing on failure except "false"
expect(result).toBe(true);

// GOOD: tells you what was in result
expect(result.status).toBe('active');
expect(result.items).toHaveLength(3);

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free