Skills test-driven-development
📦

test-driven-development

Safe

Apply Test-Driven Development

Also available from: Cycleaddict,obra,davila7,DMJGilbert,DYAI2025,Cygnusfear,CodingCossack

Writing tests after code leads to false confidence and missed edge cases. This skill enforces the TDD discipline: write a failing test first, then implement just enough code to pass.

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 "test-driven-development". I need to add a function that validates email addresses

Expected outcome:

Let me start with TDD. First, I'll write a failing test:

```typescript
test('rejects invalid email', () => {
expect(validateEmail('invalid')).toBe(false);
});
```

Now I'll run this test to confirm it fails...

Using "test-driven-development". The login function should handle wrong passwords

Expected outcome:

Following TDD, first the test:

```typescript
test('rejects wrong password', async () => {
const result = await login('user@test.com', 'wrongpass');
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
});
```

Running test to verify it fails...

Security Audit

Safe
v1 • 2/24/2026

This is a legitimate Test-Driven Development educational skill. The static analyzer detected 73 potential issues, but after semantic evaluation, all findings are FALSE POSITIVES. The 'external_commands' detections are markdown code block delimiters (backticks) in documentation, not actual shell execution. The 'weak cryptographic algorithm' and 'network reconnaissance' detections are similarly false positives triggered by keywords in educational context. No executable malicious code exists in this skill.

2
Files scanned
672
Lines analyzed
1
findings
1
Total audits
Medium Risk Issues (1)
Markdown Code Block Delimiters Flagged as Shell Execution
The static scanner detected 'Ruby/shell backtick execution' patterns in markdown files. These are FALSE POSITIVES - the backticks are markdown code fence delimiters (```typescript, ```bash) used for syntax highlighting in documentation, not runtime command execution. The skill is educational content about TDD methodology with no actual shell commands being executed.
Audited by: claude

Quality Score

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

What You Can Build

New Feature Implementation

When building a new feature, write the test first that defines the expected behavior, watch it fail, then implement to make it pass

Bug Fix Workflow

When fixing a bug, first write a test that reproduces the bug, watch it fail, then fix the code to make it pass

Refactoring with Confidence

Before refactoring, ensure tests exist. The tests verify the behavior remains correct after code changes

Try These Prompts

Start TDD for New Feature 
I need to implement [describe feature]. Following TDD, first write a failing test that defines the expected behavior. Don't write implementation code yet.
Verify Red Phase 
Run the test I just wrote and confirm it fails for the right reason (feature missing, not due to typos). Show me the exact failure message.
Green Phase - Minimal Implementation 
Now write the minimal code needed to make the test pass. Do not add extra features or refactor. Just get the test to pass.
TDD for Bug Fix 
There's a bug where [describe bug]. First write a test that reproduces this bug and fails. Then I'll fix it.

Best Practices

  • Write one test at a time - focus on single behavior
  • Name tests by the behavior they verify, not by what is being tested
  • Always watch the test fail before writing implementation
  • Keep implementation minimal - only pass the current test

Avoid

  • Writing implementation code before tests (then 'adapting' tests)
  • Keeping failed implementation code as 'reference' while writing tests
  • Tests that pass immediately - they prove nothing
  • Testing mock behavior instead of real component behavior

Frequently Asked Questions

What is Test-Driven Development?
TDD is a methodology where you write a failing test first, then write minimal code to pass it, then refactor. The cycle is: Red (fail), Green (pass), Refactor.
Why write tests before code?
Tests written after code pass immediately, proving nothing. Writing tests first forces you to define desired behavior and proves the test actually catches bugs.
What if the test is hard to write?
Difficulty writing tests often indicates the design is too complex. Simplify the interface or use dependency injection to make code testable.
Can I skip TDD for simple code?
No. Simple code still breaks. The time to write a test is minimal, and it proves the code works and prevents future regressions.
What if I already wrote the implementation?
Delete it. Start fresh with TDD. Keeping existing code and adding tests after defeats the purpose and gives false confidence.
Does TDD slow down development?
No. TDD finds bugs before commit, prevents regressions, and enables safe refactoring. Debugging after the fact is slower than TDD.

Developer Details

Author

ZhanlinCui

License

MIT

Repository

https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/test-driven-development

Ref

main

File structure

📄 SKILL.md

📄 testing-anti-patterns.md