Skills tdd
πŸ“¦

tdd

Safe

Write tests using test-driven development

Also available from: Benny9193

Writing tests after code creates fragile systems that break on refactors. This skill guides you through test-driven development where tests define behavior before implementation, resulting in cleaner code and reliable refactoring.

Supports: Claude Codex Code(CC)
πŸ₯‰ 74 Bronze
1

Download the skill ZIP

2

Upload in Claude

Go to Settings β†’ Capabilities β†’ Skills β†’ Upload skill

3

Toggle on and start using

Test it

Using "tdd". Help me build a feature to add items to a shopping cart

Expected outcome:

I'll guide you through TDD for this feature. First question: what should happen when a user adds an item? Should we support quantity? What behavior should be verifiable?

Using "tdd". Write tests for user authentication

Expected outcome:

For auth testing, focus on public interfaces: login, logout, session handling. I recommend integration-style tests over mocking internal auth logic. What external services does your auth use?

Using "tdd". I have tests that break whenever I refactor

Expected outcome:

Your tests are likely coupled to implementation details. Good tests verify behavior through public interfaces. Let's identify which tests break and what they're testing.

Security Audit

Safe
v1 β€’ 4/19/2026

All 48 static findings are false positives. The skill contains educational TDD documentation with code examples. External command flags were triggered by ASCII workflow diagrams (RED→GREEN patterns). Cryptographic algorithm flags were triggered by testing patterns like jest.mock() and StripeClient(). No malicious code or prompt injection detected.

6
Files scanned
307
Lines analyzed
0
findings
1
Total audits
No security issues found
Audited by: claude

Quality Score

38
Architecture
100
Maintainability
87
Content
50
Community
100
Security
91
Spec Compliance

What You Can Build

Building new features with TDD

When starting a new feature, this skill helps write tests first that define expected behavior, then guides minimal implementation to pass those tests.

Fixing bugs with failing tests

When a bug is reported, this skill helps write a failing test that reproduces the bug, then guides fixing the code to make the test pass.

Improving legacy code through refactoring

Before refactoring legacy code, this skill helps write integration tests that capture current behavior, ensuring refactors do not break existing functionality.

Try These Prompts

New feature with TDD
I need to add [feature] to [module]. Help me use TDD to build this. Start by asking what behaviors to test first.
Bug fix with TDD
There's a bug where [description]. Help me write a failing test that reproduces this, then fix it.
Improve test coverage
I want better tests for [module]. Review my current tests and suggest improvements following TDD principles.
Refactoring with confidence
I want to refactor [module]. Help me write tests that capture current behavior first, then guide my refactoring.

Best Practices

  • Write one test at a time and only enough code to pass it
  • Use public interfaces only; tests should survive internal refactors
  • Prefer integration-style tests that verify observable behavior over mocking internal parts

Avoid

  • Writing all tests first then all implementation (horizontal slicing)
  • Mocking internal collaborators instead of testing through public interfaces
  • Writing tests that verify implementation details rather than behavior

Frequently Asked Questions

When should I write tests in TDD?
Write the test before any implementation code. The test defines what behavior you want before you build it.
How many tests should I write at once?
Write one test at a time. This keeps your cycles small and focused on one behavior at a time.
What should I test if I cannot test everything?
Focus on critical paths and complex logic. Confirm with your user which behaviors matter most for your application.
Should I mock my own classes or modules?
No. Only mock at system boundaries like external APIs, databases, and file systems. Your own code should be tested through real interfaces.
When should I refactor in TDD?
Only refactor when all tests pass (in green state). Never refactor while tests are failing.
How do I know if my test is good?
A good test breaks when behavior breaks but survives internal refactors. If renaming an internal function breaks your test, the test was testing implementation not behavior.

Developer Details

File structure

πŸ“„ deep-modules.md

πŸ“„ interface-design.md

πŸ“„ mocking.md

πŸ“„ refactoring.md

πŸ“„ SKILL.md

πŸ“„ tests.md