Enforces test-driven development — tests before code — with 80%+ coverage across unit, integration, and E2E tests, including edge cases and error scenarios. USE WHEN writing a new feature or functionality, fixing a bug, refactoring existing code, adding an API endpoint, or creating a new component.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Enforces test-driven development — tests before code — with 80%+ coverage across unit, integration, and E2E tests, including edge cases and error scenarios. USE WHEN writing a new feature or functionality, fixing a bug, refactoring existing code, adding an API endpoint, or creating a new component.
origin
ECC
cluster
quality-eval
version
1.0.0
Test-Driven Development Workflow
This skill ensures all code development follows TDD principles with comprehensive test coverage.
When to Activate
Writing new features or functionality
Fixing bugs or issues
Refactoring existing code
Adding API endpoints
Creating new components
Core Principles
1. Tests BEFORE Code
ALWAYS write tests first, then implement code to make tests pass.
2. Coverage Requirements
Minimum 80% coverage (unit + integration + E2E)
All edge cases covered
Error scenarios tested
Boundary conditions verified
3. Test Types
Unit Tests
Individual functions and utilities
Component logic
Pure functions
Helpers and utilities
Integration Tests
API endpoints
Database operations
Service interactions
External API calls
E2E Tests (Playwright)
Critical user flows
Complete workflows
Browser automation
UI interactions
4. Git Checkpoints
If the repository is under Git, create a checkpoint commit after each TDD stage
Do not squash or rewrite these checkpoint commits until the workflow is complete
Each checkpoint commit message must describe the stage and the exact evidence captured
Count only commits created on the current active branch for the current task
Do not treat commits from other branches, earlier unrelated work, or distant branch history as valid checkpoint evidence
Before treating a checkpoint as satisfied, verify that the commit is reachable from the current HEAD on the active branch and belongs to the current task sequence
The preferred compact workflow is:
one commit for failing test added and RED validated
one commit for minimal fix applied and GREEN validated
one optional commit for refactor complete
Separate evidence-only commits are not required if the test commit clearly corresponds to RED and the fix commit clearly corresponds to GREEN
TDD Workflow Steps
Step 1: Write User Journeys
As a [role], I want to [action], so that [benefit]
Example:
As a user, I want to search for markets semantically,
so that I can find relevant markets even without exact keywords.
Step 2: Generate Test Cases
For each user journey, create comprehensive test cases:
describe('Semantic Search', () => {
it('returns relevant markets for query', async () => {
// Test implementation
})
it('handles empty query gracefully', async () => {
// Test edge case
})
it('falls back to substring search when Redis unavailable', async () => {
// Test fallback behavior
})
it('sorts results by similarity score', async () => {
// Test sorting logic
})
})
Step 3: Run Tests (They Should Fail)
npm test# Tests should fail - we haven't implemented yet
This step is mandatory and is the RED gate for all production changes.
Before modifying business logic or other production code, you must verify a valid RED state via one of these paths:
Runtime RED:
The relevant test target compiles successfully
The new or changed test is actually executed
The result is RED
Compile-time RED:
The new test newly instantiates, references, or exercises the buggy code path
The compile failure is itself the intended RED signal
In either case, the failure is caused by the intended business-logic bug, undefined behavior, or missing implementation
The failure is not caused only by unrelated syntax errors, broken test setup, missing dependencies, or unrelated regressions
A test that was only written but not compiled and executed does not count as RED.
Do not edit production code until this RED state is confirmed.
If the repository is under Git, create a checkpoint commit immediately after this stage is validated.
Recommended commit message format:
test: add reproducer for <feature or bug>
This commit may also serve as the RED validation checkpoint if the reproducer was compiled and executed and failed for the intended reason
Verify that this checkpoint commit is on the current active branch before continuing
Step 4: Implement Code
Write minimal code to make tests pass:
// Implementation guided by testsexportasyncfunctionsearchMarkets(query: string) {
// Implementation here
}
If the repository is under Git, stage the minimal fix now but defer the checkpoint commit until GREEN is validated in Step 5.
Step 5: Run Tests Again
npm test# Tests should now pass
Rerun the same relevant test target after the fix and confirm the previously failing test is now GREEN.
Only after a valid GREEN result may you proceed to refactor.
If the repository is under Git, create a checkpoint commit immediately after GREEN is validated.
Recommended commit message format:
fix: <feature or bug>
The fix commit may also serve as the GREEN validation checkpoint if the same relevant test target was rerun and passed
Verify that this checkpoint commit is on the current active branch before continuing
Step 6: Refactor
Improve code quality while keeping tests green:
Remove duplication
Improve naming
Optimize performance
Enhance readability
If the repository is under Git, create a checkpoint commit immediately after refactoring is complete and tests remain green.
Recommended commit message format:
refactor: clean up after <feature or bug> implementation
Verify that this checkpoint commit is on the current active branch before considering the TDD cycle complete
Step 7: Verify Coverage
npm run test:coverage
# Verify 80%+ coverage achieved
// Resilient to changesawait page.click('button:has-text("Submit")')
await page.click('[data-testid="submit-button"]')
FAIL: WRONG: No Test Isolation
// Tests depend on each othertest('creates user', () => { /* ... */ })
test('updates same user', () => { /* depends on previous test */ })
PASS: CORRECT: Independent Tests
// Each test sets up its own datatest('creates user', () => {
const user = createTestUser()
// Test logic
})
test('updates user', () => {
const user = createTestUser()
// Update logic
})
Continuous Testing
Watch Mode During Development
npm test -- --watch
# Tests run automatically on file changes
Pre-Commit Hook
# Runs before every commit
npm test && npm run lint
