Skip to content
Development
Skill

/testing

Testing: TDD, E2E, preferred patterns, verification, agent testing.

From plugin
vexjoy-agent
42561 skills198 agents12 commands78 hooks
Install
$ npx -y skills add notque/vexjoy-agent --skill testing --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/testing

Context preview

The summary Claude sees to decide when to auto-load this skill.

Testing: TDD, E2E, preferred patterns, verification, agent testing.

SKILL.md

testing.SKILL.md
name: testing
description: "Testing: TDD, E2E, preferred patterns, verification, agent testing."
user-invocable: false
allowed-tools:
  - Read
  - Write
  - Bash
  - Grep
  - Glob
  - Edit
  - Task
  - Skill
  - Agent
agent: testing-automation-engineer
routing:
  not_for: "code review (use review), linting (use code-quality)"
  triggers:
    - "TDD"
    - "test first"
    - "red green refactor"
    - "write tests first"
    - "test-driven"
    - "tests before code"
    - "flaky test"
    - "brittle test"
    - "test smell"
    - "test quality issue"
    - "slow tests"
    - "over-mocking"
    - "test agents"
    - "agent testing"
    - "subagent testing"
    - "run vitest"
    - "JavaScript tests"
    - "TypeScript tests"
    - "playwright"
    - "E2E test"
    - "end-to-end"
    - "browser test"
    - "verify completion"
    - "run tests"
    - "final verification"
  category: testing
  pairs_with:
    - review
    - code-quality
    - workflow

Testing

Six modes. Match the request to one mode and follow its section. Read repository CLAUDE.md first -- project conventions override defaults here.

Mode Selection

| Request matches | Go to | |---|---| | Write tests first, TDD, red-green-refactor | **TDD** | | Flaky, brittle, test smell, over-mocking, slow tests | **Pattern Quality** | | Test an agent, subagent testing, validate agent | **Agent Testing** | | Run vitest, JavaScript/TypeScript tests | **Vitest Runner** | | Playwright, E2E, end-to-end, browser test | **E2E (Playwright)** | | Verify completion, final check, defense in depth | **Verification** |

---

TDD

RED-GREEN-REFACTOR cycle with strict phase gates. Each feature gets its own cycle. Do not batch multiple features into one cycle.

Phase 1: RED -- Write a Failing Test

Write a test describing desired behavior before implementation exists. Use Arrange-Act-Assert, descriptive names, one concept per test. Run the test and show full output.

**Gate** -- proceed only when all true:

  • Test file created and saved
  • Test executed
  • Output shows FAILURE (not syntax/import error)
  • Failure indicates missing implementation

If test passes before implementation: assertions are too weak, or the feature already exists. If test fails for wrong reason (syntax, import, setup): fix those first, then re-run until it fails for the right reason.

Phase 2: GREEN -- Minimum Implementation

Write ONLY enough code to make the failing test pass. No extra features. Hardcoded values are acceptable initially. Run the test and the full suite; show complete output.

**Gate** -- proceed only when all true:

  • New test passes
  • Full suite executed
  • No other tests broken

Phase 3: REFACTOR

Improve code quality without changing behavior. Establish a green baseline, refactor incrementally, run tests after every step. Test behavior, not internals.

**Gate** -- proceed only when all true:

  • Full suite passes
  • Code quality evaluated

Phase 4: Commit

Commit test and implementation as an atomic unit. Run the full suite first.

TDD Error Recovery

| Symptom | Cause | Fix | |---|---|---| | Test passes in RED phase | Weak assertions or feature exists | Strengthen assertions; check for existing implementation | | Wrong failure reason | Setup incomplete, missing deps | Fix syntax/imports first, re-run | | Tests green but feature broken | Tests miss actual usage | Add integration tests; test with real data | | Refactoring breaks tests | Tests coupled to internals | Test behavior not implementation; refactor in smaller steps |

---

Pattern Quality

Identify and fix testing mistakes across unit, integration, and E2E suites. Test behavior, be reliable, run fast, fail for the right reasons.

Phase 1: SCAN

Locate test files (`*_test.go`, `test_*.py`, `*.test.ts`, `*.spec.js`). Scan for these 10 failure modes:

| # | Pattern | Detection Signal | |---|---|---| | 1 | Testing implementation details | Asserts on private fields, spy on private methods | | 2 | Over-mocking / brittle selectors | Mock setup > 50% of test code, CSS nth-child | | 3 | Order-dependent tests | Shared mutable state, numbered test names | | 4 | Incomplete assertions | `!= nil`, `> 0`, `toBeTruthy()`, no value checks | | 5 | Over-specification | Exact timestamps, hardcoded IDs, asserting defaults | | 6 | Ignored failures | `@skip`, `.skip`, `xit`, empty catch, `_ = err` | | 7 | Poor naming | `testFunc2`, `it('works')`, `it('handles case')` | | 8 | Missing edge cases | Only happy path, no empty/null/boundary/error tests | | 9 | Slow test suites | Full DB reset per test, no parallelization | | 10 | Flaky tests | `sleep()`, `time.Sleep()`, unsynchronized goroutines |

Document each finding with file:line, severity, issue, and impact.

**Gate**: At least one quality issue identified with file:line reference.

Phase 2: PRIORITIZE

1. **HIGH** -- Flaky, order-dependent, ignored failures (erode trust) 2. **MEDIUM** -- Over-mocking, incomplete assertions, missing edges (false confidence) 3. **LOW** -- Poor naming, over-specification, slow suites (maintenance burden)

Fix one pattern at a time. Preserve test intent. Prevent over-engineering.

**Gate**: Findings ranked. User agrees on fix scope.

Phase 3: FIX

For each issue (highest priority first): show current code, show fixed code, apply fix, run tests. Guide toward behavior testing:

  • Asserts on private fields -> test the public behavior those fields enable
  • Spies on `_getUser()` -> test what happens when a user exists or not
  • Checks exact regex -> test that validation succeeds/fails for representative inputs

Run the specific fixed test first, then the full file or package. If a fix breaks a previously-passing test, investigate before proceeding.

**Gate**: Each fix verified. Tests pass after each change.

Phase 4: VERIFY

Run full suite. Verify flaky tests are now deterministic (run 3x). Confirm no no tests were accidentally removed or disabled. Report: bad patterns fixed, files modified, tests affect

Read more
Ships withvexjoy-agent

Essays and writing behind this toolkit live at vexjoy.com. VexJoy Agent connects plain-English requests to specialist agents, skills, and workflows. /do selects the knowledge and tools needed for your task.

Get the whole plugin

Other skills on vexjoy-agent.