Red-Green-Refactor TDD Loop
Real test-driven development: every test seen failing for the right reason first, minimal code to pass, refactor on green.
Before & after
Same prompt, same agent — the only difference is the skill.
Test-driven development is an important methodology for writing reliable code. When building a user auth module, you'll want to think about what the key behaviors are that need to be tested. Some good starting points might be testing login flows, verifying that passwords are handled securely, and making sure user sessions work correctly. You could also consider edge cases like invalid inputs or network failures. There are various testing frameworks available depending on your language choice. Would you like me to help you explore which testing approach might work best for your use case?
TDD WORKFLOW FOR AUTH MODULE:
1. TEST LAYER DESIGN
Start with test names that express behavior, not implementation:
• describe('UserAuthService', () => {)
• it('rejects login with invalid email format')
• it('hashes password before storage using bcrypt')
• it('expires session token after 24 hours')
• it('throws specific error for locked account')
2. RED PHASE - Write failing tests first
Define the exact contract your auth module must fulfill before touching implementation code. Test names should read like requirements.
3. GREEN PHASE - Minimal implementation
Add only the code needed to pass tests. Skip validation logic, error paths, and edge cases not yet tested.
4. REFACTOR PHASE - Improve without changing behavior
Reduce duplication between tests. Extract test fixtures. Move mock setup to beforeEach blocks.
5. COVERAGE CHECKLIST
Root cause bugs by testing inverted assumptions: test that password comparison fails with wrong hash, test that token expiry actually rejects expired tokens, not just accepts valid ones.
Priority sequence: auth happy path → security constraints → error messages → rate limiting.
About this skill
Most AI "TDD" writes the code and tests together and ends with a suite that would pass even if the feature broke. This skill enforces the part that matters: every test is seen failing for the right reason before any code makes it pass.
What it does
- Finds the project's real test command and checks the suite is green before starting
- Builds a behavior-first test list and runs one red-green-refactor cycle at a time
- Verifies tests fail on the assertion, not on typos or missing imports
- Blocks fake TDD: never-red tests, edited assertions, mocking the code under test, snapshot shortcuts, flaky time and randomness
- Handles bug fixes (regression test first) and legacy code (characterization tests first)
What you get
A cycle-by-cycle log of red and green runs, the finished test list, and the command to run the full suite.
Best for
Developers who want Claude Code to write tests that actually prove behavior, and teams that require test-first bug fixes.
SKILL.md preview
---
name: tdd
description: Drive a code change with real red-green-refactor test-driven development - write one failing test, run it and confirm it fails for the right reason, write the least code to pass, refactor with the suite green - and avoid the ways AI-assisted TDD goes fake (tests written after the code, tests that never went red, assertions on mocks, tests edited to pass). Use when the user says "do this with TDD", "test first", "red green refactor", "write a failing test for this bug first", "add tests before changing this legacy code", or casually "write the test before the fix" or "prove the bug with a test".
---
# Red-Green-Refactor TDD Loop
… (sign up to view the full skill)More development skills
View all Development skills →React and Next.js Regression Test Coverage
Generate React and Next.js tests with Jest, Testing Library, MSW, and Playwright, prioritized by regression risk.
Playwright E2E Tests and Flake Repair
Build reliable Playwright tests, repair flakes from evidence, migrate suites, and configure faster, diagnosable CI.
Pre-Ship Verification for Code Changes
Before calling a code change done, Claude grades every claim by evidence, tries to break it, and reports what's verified vs assumed.
TestRail Case and CI Result Sync
Sync automated tests to TestRail cases and scoped runs with stable mappings, retry handling, and verified result counts.