TDD Workflow
hellangleZ/burn-in-cceverywhere-ralph
A skill your agent uses when writing new features, fixing bugs, or refactoring code.
Testing: TDD, E2E, preferred patterns, test-value audits, verification, agent testing.
Install Testing
$ npx skills add notque/vexjoy-agent --skill testing -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install notque/vexjoy-agent testing --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/notque/vexjoy-agent.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/process/testing .claude/skills/testing && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "testing" agent skill from https://github.com/notque/vexjoy-agent/tree/main/skills/process/testing into .claude/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/notque/vexjoy-agent/tree/main/skills/process/testingType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add notque/vexjoy-agent --skill testing -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install notque/vexjoy-agent testing --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/notque/vexjoy-agent.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/process/testing .agents/skills/testing && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "testing" agent skill from https://github.com/notque/vexjoy-agent/tree/main/skills/process/testing into .agents/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add notque/vexjoy-agent --skill testing -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install notque/vexjoy-agent testing --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/notque/vexjoy-agent.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/process/testing .cursor/skills/testing && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "testing" agent skill from https://github.com/notque/vexjoy-agent/tree/main/skills/process/testing into .cursor/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/notque/vexjoy-agent.git --path skills/process/testing--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add notque/vexjoy-agent --skill testing -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install notque/vexjoy-agent testing --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/notque/vexjoy-agent.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/process/testing .gemini/skills/testing && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "testing" agent skill from https://github.com/notque/vexjoy-agent/tree/main/skills/process/testing into .gemini/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install notque/vexjoy-agent testingInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add notque/vexjoy-agent --skill testing -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/notque/vexjoy-agent.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/process/testing .github/skills/testing && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "testing" agent skill from https://github.com/notque/vexjoy-agent/tree/main/skills/process/testing into .github/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add notque/vexjoy-agent --skill testing -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install notque/vexjoy-agent testing --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/notque/vexjoy-agent.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/process/testing .opencode/skills/testing && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "testing" agent skill from https://github.com/notque/vexjoy-agent/tree/main/skills/process/testing into .opencode/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
testing- GitHub stars
- 435
- Token cost
- ~4.7k tokens
- SKILL.md length
- 2,224 words
- Files
- 20 (incl. references)
- Skills in repo
- 61
- Repo updated
- First seen
- Licence
- MIT
At a glance
Testing: TDD, E2E, preferred patterns, test-value audits, verification, agent testing.
- Works in 12 steps: RED -- Write a Failing Test → GREEN -- Minimum Implementation → REFACTOR → …
- Tasks that involve Test-driven development
- SKILL.md covers Mode Selection, TDD, Pattern Quality and Test Audit, plus 4 more sections
- Calls npx, npm and cargo
What it does
Testing is an agent skill from notque/vexjoy-agent. Testing: TDD, E2E, preferred patterns, test-value audits, verification, agent testing.
Its SKILL.md is about 4.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 20 other files, including reference files (for example `references/agents-examples-and-errors.md`, `references/agents-testing-patterns.md` and `references/audit-test-value.md`).
It sits in Testing & QA, covering Test-driven development, Agent evaluation and testing and End-to-end testing. The repository describes itself as: VexJoy AI Agent with Jev Intelligent Routing - /do routes plain-English requests to the right specialist agent and gates the work with reviews, tests, and a learning loop. The licence is MIT.
When your agent uses it
- Tasks that involve Test-driven development
- Tasks that involve Agent evaluation and testing
- Tasks that involve End-to-end testing
Example prompts
- “/testing”
Requirements
- Node.js
- Pre-approved tools (allowed-tools): Read, Write, Bash, Grep, Glob, Edit, Task, Skill, Agent
Workflow steps
12 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit 5218674. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves these tools, so the agent can use them without asking each time:
ReadWriteBashGrepGlobEditTaskSkillAgent
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
npxnpmcargogitgopytestpythonruff
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use npx, npm and git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Testing loads about 4.7k tokens when it runs, and up to ~46k if it reads all its reference files. Until then it costs about 24 tokens; SKILL.md has 2,224 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check: notes
The automated check noted patterns worth knowing about, such as sudo or a known installer.
- NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
allowed-tools: Read, Write, Bash, Grep, Glob, Edit, Task, Skill, Agent
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from notque/vexjoy-agent at commit 5218674, republished under its MIT licence (© notque). 2,224 words, ~4,689 tokens.
Download SKILL.mdSave it as
.claude/skills/testing/SKILL.md (or your agent's skills folder). This skill also uses 19 other files; get the full folder from GitHub.- name
- testing
- description
- Testing: TDD, E2E, preferred patterns, test-value audits, verification, agent testing.
- allowed-tools
- Read, Write, Bash, Grep, Glob, Edit, Task, Skill, Agent
- user-invocable
- false
- agent
- testing-automation-engineer
- routing.not_for
- code review (use review), linting (use code-quality)
- routing.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…
- routing.category
- testing
- routing.pairs_with
- review, code-quality, workflow
Testing
Seven 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 |
| Audit or prune low-value, duplicate, or implementation-coupled tests | Test Audit |
| 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.
Every new or changed test, in any mode, must first pass the authoring gate in
references/audit-test-value.md.
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
- HIGH -- Flaky, order-dependent, ignored failures (erode trust)
- MEDIUM -- Over-mocking, incomplete assertions, missing edges (false confidence)
- 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 affected, suite status.
Gate: Full suite passes. Summary delivered.
Pattern Error Recovery
| Problem | Fix |
|---|---|
| Cannot determine if pattern is a quality issue | Check comments, consider test layer, flag MEDIUM with trade-offs |
| Fix changes test behavior | Identify original intent, write correct assertion, note as separate finding |
| Suite has hundreds of quality issues | Fix HIGH severity first, recommend TDD going forward, suggest fix-on-touch |
Test Audit
Find and remove tests that do not earn their maintenance cost, and the
test-only production seams they keep alive. Load
references/audit-test-value.md and follow it; it holds the authoring gate,
junk patterns, retention bar, evidence fields, validation, and handoff.
Use Pattern Quality to fix a test that guards real behavior badly. Use Test Audit to decide whether a test should exist at all.
| Scope | Sub-mode |
|---|---|
| Writing or changing a test | Authoring gate |
| Focused sweep of a few candidates | Audit |
| Every test one subsystem owns | Campaign |
Gate: Every deletion has all candidate evidence fields recorded. Owner and full suites pass. Production and test LOC reported separately.
Agent Testing
TDD methodology applied to agent development. Test what the agent DOES, not what the prompt SAYS. Each test runs in a fresh subagent to avoid context pollution.
Minimum Test Counts
| Agent Type | Min Tests | Coverage |
|---|---|---|
| Reviewer | 6 | 2 real issues, 2 clean, 1 edge, 1 ambiguous |
| Implementation | 5 | 2 typical, 1 complex, 1 minimal, 1 error |
| Analysis | 4 | 2 standard, 1 edge, 1 malformed |
| Routing/orchestration | 4 | 2 correct route, 1 ambiguous, 1 invalid |
No agent is simple enough to skip testing.
Phase 1: RED -- Observe Current Behavior
Read the agent file and referenced skills. Extract testable claims (inputs, output structure, routing triggers, error conditions). Write a test plan to a file. Dispatch subagent via Task tool with test inputs. Capture results verbatim. Identify failure patterns.
Gate: All cases executed. Outputs captured. Failures documented.
Phase 2: GREEN -- Fix Agent Definition
Prioritize failures by severity. Make one fix at a time. Re-run ALL test cases after each fix. If a fix causes regression, revert and try a different approach.
Gate: All cases pass. No regressions.
Phase 3: REFACTOR -- Edge Cases and Robustness
Add edge case tests (empty, large, unusual, ambiguous inputs). Run consistency tests (same input 3x; outputs should have same structure and key findings). Run full regression suite.
Gate: Edge cases handled. Consistency verified. Full suite green.
Vitest Runner
Run existing Vitest tests and report results. A check-only request does not authorize changing tests, assertions, dependencies, or configuration.
Check package.json, vitest.config.*, and vite.config.* to confirm Vitest.
Use the installed project version; avoid implicit npx downloads. If Vitest is
unavailable, report setup needed rather than installing it. Always use run;
bare vitest enters watch mode.
| Scope | Command |
|---|---|
| Full suite | npx vitest run --reporter=verbose 2>&1 |
| File or directory | npx vitest run path/to/test.ts 2>&1 |
| Test-name pattern | npx vitest run -t "pattern" 2>&1 |
| Coverage | npx vitest run --coverage 2>&1 |
Capture exit code and full output. Report pass/fail, scope, counts, duration. For failures: retain file, test name, assertion diff, relevant stack. Nonzero exit is failure; partial output is not a passing run.
Vitest Recovery
| Problem | Fix |
|---|---|
| Vitest missing / no node_modules | npm install or npm install -D vitest |
| No test files found | Check naming (*.test.ts, *.spec.ts) and include/exclude globs |
| Missing DOM environment | Check for jsdom/happy-dom in config; suggest devDependency |
| Out of memory | Batch by directory, use --pool=forks or --shard=1/N |
| Failing assertions | Report mismatch; if fixing authorized, determine whether implementation or test is wrong |
E2E (Playwright)
Playwright-based E2E testing: Scaffold, Build, Run, Validate. Each phase produces an artifact and must pass its gate.
Phase 1: SCAFFOLD
- Verify
@playwright/testinstalled:npx playwright --version. If missing:npm install -D @playwright/test && npx playwright install. - Create directory structure:
tests/e2e/{auth,features,api}/,pages/,artifacts/{screenshots,traces,videos}/. - Write
playwright.config.ts. Bake in failure diagnostics:screenshot: 'only-on-failure',trace: 'on-first-retry',video: 'retain-on-failure'. CI retries:retries: process.env.CI ? 2 : 0. - Verify:
npx tsc --noEmit.
Gate: playwright.config.ts exists AND tests/e2e/ exists.
Show full SKILL.md (889 more words)Show less
Phase 2: BUILD
Write POM classes in pages/ for each feature area. All locators use
data-testid via page.getByTestId(). No inline locators in spec files.
Write spec files in tests/e2e/<area>/. Verify: npx tsc --noEmit.
Gate: At least one .spec.ts under tests/e2e/ AND npx tsc --noEmit
exits 0.
Phase 3: RUN
- Ensure app is running (or document
BASE_URL). - Run:
npx playwright test. - If failures, isolate with
--repeat-each=5to distinguish flaky from broken. - Quarantine confirmed flaky tests with
test.fixme()and a tracking TODO. Never delete a failing test. Usetest.skip()only for environment guards.
Gate: playwright-results.json exists and parses as valid JSON.
Phase 4: VALIDATE
- Deterministic checks first: parse JSON, extract counts, identify
unexpectedandflakyentries. - LLM triage: classify each failure as (a) broken assertion, (b) selector mismatch, (c) timing/async, or (d) application bug.
- Write
e2e-report.md.
Gate: e2e-report.md exists.
E2E Error Recovery
| Symptom | Fix |
|---|---|
npx tsc --noEmit fails | Check @playwright/test in devDeps, verify tsconfig includes test dir |
| Pass locally, fail CI | npx playwright install --with-deps in CI; verify BASE_URL |
| Results JSON missing | Check JSON reporter in config; check for OOM/process kill |
| Locator timeout on existing element | await expect(locator).toBeVisible() before interaction; check overlays |
fill() appends | locator.clear() then locator.fill() |
| Flaky (4/5 pass) | Quarantine with test.fixme(), reproduce with --repeat-each=10, check missing waitFor |
Confirm flaky vs. broken: --repeat-each=5 --retries=0. If fails at least once
in 5, it is flaky. Fix if root cause is clear; quarantine otherwise. Verify fix
with --repeat-each=10 --retries=0 (must pass 10/10).
Verification
Defense-in-depth verification before declaring any task complete. Match checks to affected behavior and repository requirements.
Steps
- Inspect changes.
git status --shortandgit diff. Read changed code; check imports, error handling, compatibility, unintended edits. - Run required checks. Tests, build, lint, format per repository config. Start with relevant tests; run full affected suite when shared behavior changed. Do not substitute syntax checks for behavior tests.
- Verify artifacts. Check generated artifacts at expected paths. For integrations, verify four levels: EXISTS on disk, SUBSTANTIVE implementation, WIRED into callers, real DATA FLOWS through it. An unused file or hardcoded empty result is not a working feature.
- Inspect diff for problems. Debug code, secrets, placeholders, unfinished
work. Review in context: an intentional
passis not automatically a stub. - Fix and rerun. Fix failures within authorized scope; rerun affected checks. A failed required build or test blocks a success claim.
- Report. Commands, observed status, counts, limitations. Retain full logs; show actionable excerpts. Distinguish automated, manual, and unrun checks.
Default Commands
| Language | Tests | Build/syntax | Lint |
|---|---|---|---|
| Python | pytest -v | python -m py_compile {files} | ruff check {files} |
| Go | go test ./... -v -race | go build ./... | golangci-lint run ./... |
| JavaScript | npm test | npm run build | npm run lint |
| TypeScript | npm test | npx tsc --noEmit | npm run lint |
| Rust | cargo test | cargo build | cargo clippy |
Evidence Reuse
Reuse a passing result when it covers the current task, checked files, dependencies, and environment. Keep its command, scope, state, and log path. After edits, rerun affected checks. Do not claim inherited results as your own. Required CI checks still apply to the delivered commit.
Verification Recovery
| Problem | Fix |
|---|---|
| No tests | Manual checks; state coverage gap; add regression test if warranted |
| Missing dependencies | Use repo environment; report missing tool; unrun checks are not passes |
| Build/test failure | Retain failing command and diagnostic; identify cause, fix, rerun |
| Missing wiring or data flow | Name where integration stops; repair it |
Anti-Rationalization
| Rationalization | Required Action |
|---|---|
| "I loaded the patterns, that's enough" | Loading is not applying. Check against patterns at each gate. |
| "This task is simple, full rigor is overkill" | Apply proportionate rigor, never zero. |
| "The gate basically passes" | Either it passes with evidence or it does not. |
Completion self-check: Did I verify or assume? Did I run tests or just read code? Did I complete everything or just the "important" parts? Can I show evidence?
Deep References
Load when the signal applies.
| Signal | Load | Content |
|---|---|---|
| TDD phase steps, language commands | references/tdd-phase-guidance.md | RED-GREEN-REFACTOR steps per language |
| TDD walkthroughs | references/tdd-examples.md | Go, Python, JavaScript worked examples |
| BAD/GOOD code per failure mode | references/patterns-preferred-pattern-catalog.md | Code examples per pattern per language |
| Failure mode classification | references/patterns-quality-catalog.md | 10 failure mode descriptions |
| Language-specific fix strategies | references/patterns-fix-strategies.md | Fix patterns and tooling per language |
| Test blind spots | references/patterns-blind-spot-taxonomy.md | 6-category gap taxonomy |
| Load test scenarios | references/patterns-load-test-scenarios.md | Smoke, stress, spike, soak configs |
| New-test gate, test audits, pruning campaigns | references/audit-test-value.md | Authoring gate, junk patterns, retention bar, evidence, validation |
| Agent dispatch patterns | references/agents-testing-patterns.md | Dispatch, negative, A/B |
| Agent testing examples | references/agents-examples-and-errors.md | Worked examples and error cases |
| E2E async patterns | references/e2e-async.md | Promise.all, race conditions, teardown |
| E2E auth testing | references/e2e-auth.md | Login, storageState, OAuth, SSO, JWT |
| E2E config templates | references/e2e-templates.md | playwright.config.ts, POM, CI/CD |
| E2E POM and waiting | references/e2e-playwright-patterns.md | POM examples, multi-browser |
| E2E Web3 wallet | references/e2e-wallet-testing.md | MetaMask testing patterns |
| E2E financial flows | references/e2e-financial-flows.md | Payment flow testing |
| Stub detection | references/verify-adversarial-methodology.md | Four-level checks, goal-backward verification |
| Domain checklists | references/verify-checklist.md | Schema change, compatibility checks |
| Verification examples | references/verify-verification-examples.md | Bug fix, refactor, migration walkthroughs |
Quick Reference: Red Flags
@skip,@ignore,xit,.skipwithout expiration datetime.sleep(),setTimeout()in test code- Test names with sequential numbers (
test1,test2) - Global mutable state accessed by multiple tests
- Mock setup spanning 20+ lines
- Empty catch blocks in tests
- Assertions like
!= nil,> 0,toBeTruthy()without value checks
Strict TDD prevents most quality issues: RED catches incomplete assertions, GREEN minimum prevents over-specification, watching failure confirms you test behavior not mocks, incremental cycles prevent interdependence, refactor phase reveals implementation coupling.
© notque, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 19 other files (references) in skills/process/testing of notque/vexjoy-agent.
- SKILL.md
- references/agents-examples-and-errors.md
- references/agents-testing-patterns.md
- references/audit-test-value.md
- references/e2e-async.md
- references/e2e-auth.md
- references/e2e-financial-flows.md
- references/e2e-playwright-patterns.md
- references/e2e-templates.md
- references/e2e-wallet-testing.md
- references/patterns-blind-spot-taxonomy.md
- references/patterns-fix-strategies.md
- references/patterns-load-test-scenarios.md
- references/patterns-preferred-pattern-catalog.md
- references/patterns-quality-catalog.md
- references/tdd-examples.md
- references/tdd-phase-guidance.md
- references/verify-adversarial-methodology.md
- references/verify-checklist.md
- references/verify-verification-examples.md
Open the folder on GitHubat commit 5218674
Compare with similar skills
Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Testing this skillnotque/vexjoy-agent | 435 | — | ~4.7k | Automated safety check: Notes | MIT | |
| TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph | 112 | 11 repos | ~2.4k | Automated safety check: Pass | None | |
| Bmad Testarch Atddbmad-code-org/bmad-method-test-architecture-enterprise | 104 | 3 repos | ~893 | Automated safety check: Pass | Custom licence | |
| Agentic TDDreticlehq/reticle | 1.2k | — | ~1.2k | Automated safety check: Pass | Apache-2.0 | |
| Openspec Plus TDDelastic/terraform-provider-elasticstack | 210 | 1 repos | ~4.7k | Automated safety check: Pass | Apache-2.0 | |
| Bmad Tea Testarch Atddchenjackle45/SayIt | 114 | 1 repos | ~225 | Automated safety check: Pass | MIT |
Similar skills
Bmad Testarch Atdd
bmad-code-org/bmad-method-test-architecture-enterprise
Generate red-phase acceptance test scaffolds using the TDD cycle.
Agentic TDD
reticlehq/reticle
Applies red-green TDD to behavior unit tests cannot reach, by stating the expected outcome against the running app with Reticle before writing the feature.
- Official
Openspec Plus TDD
elastic/terraform-provider-elasticstack
MANDATORY skill that activates whenever code is written to implement an OpenSpec change task.
Bmad Tea Testarch Atdd
chenjackle45/SayIt
Generate failing acceptance tests using TDD cycle. An agent skill from chenjackle45/SayIt.
Atdd
swingerman/engineer
A skill your agent uses to drive feature work through the Acceptance Test Driven Development workflow — Given/When/Then specs before code, a project-specific test pipeline, and two parallel test…
More from notque/vexjoy-agent
All 61 skills in this repoGame Asset Generator
notque/vexjoy-agent
Deterministic palette/matrix pixel art (not AI). An agent skill from notque/vexjoy-agent.
PR Workflow
notque/vexjoy-agent
Pull request lifecycle: commit, codex review, sync, review, fix, status, cleanup, and PR mining.
Architecture Deepening
notque/vexjoy-agent
Improve architecture across modules by deepening interfaces.
Code Quality
notque/vexjoy-agent
Code quality: cleanup, linting, formatting, quality gates. An agent skill from notque/vexjoy-agent.
Codebase Analyzer
notque/vexjoy-agent
Statistical rule discovery from Go codebase patterns. An agent skill from notque/vexjoy-agent.
Comment Quality
notque/vexjoy-agent
Review and fix temporal references in code comments. An agent skill from notque/vexjoy-agent.
Related
Categories
Questions about Testing
What does Testing do?
Testing: TDD, E2E, preferred patterns, test-value audits, verification, agent testing. Testing is an agent skill from notque/vexjoy-agent. Testing: TDD, E2E, preferred patterns, test-value audits, verification, agent testing.
When should I use Testing?
Testing fits situations like: tasks that involve Test-driven development; tasks that involve Agent evaluation and testing; tasks that involve End-to-end testing.
How do I install Testing in Claude Code?
Run `npx skills add notque/vexjoy-agent --skill testing -a claude-code`. Or copy the skill folder (skills/process/testing in notque/vexjoy-agent) into .claude/skills/testing in your project. Claude Code loads it when a task matches its description.
How do I install Testing in Codex?
Run `npx skills add notque/vexjoy-agent --skill testing -a codex`. Or copy the skill folder (skills/process/testing in notque/vexjoy-agent) into .agents/skills/testing in your project. Codex loads it when a task matches its description.
Can I use Testing in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add notque/vexjoy-agent --skill testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/testing, .gemini/skills/testing, .github/skills/testing and .opencode/skills/testing in your project.
What does Testing need to run?
Going by SKILL.md and its folder, Testing needs the command-line tools its instructions call (npx, npm, cargo, git, go and pytest). Our summary lists: Node.js. Its frontmatter pre-approves these tools: Read, Write, Bash, Grep, Glob, Edit, Task, Skill, Agent.
Does Testing access the network?
SKILL.md contains no URLs. Its commands use npx, npm and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Testing safe to install?
Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.
What licence does Testing use?
Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Testing use?
About 4.7k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 42k tokens, read only when the agent opens those files.
What are the alternatives to Testing?
Skills that share tags, products or a category with Testing: TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars), Bmad Testarch Atdd (bmad-code-org/bmad-method-test-architecture-enterprise, 104 stars), Agentic TDD (reticlehq/reticle, 1.2k stars) and Openspec Plus TDD (elastic/terraform-provider-elasticstack, 210 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Testing?
notque (a GitHub user) maintains it in notque/vexjoy-agent, which has 435 GitHub stars. The repository holds 61 skills in this directory. The repository was last updated on October 3, 2026.
Source: notque/vexjoy-agent on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.