claude-mpm 4.21.3__py3-none-any.whl → 5.1.9__py3-none-any.whl

claude_mpm/skills/bundled/testing/test-driven-development/references/anti-patterns.md

@@ -1,543 +0,0 @@
-# TDD Anti-Patterns
-
-> **Part of**: [Test-Driven Development](../SKILL.md)
-> **Category**: testing
-> **Reading Level**: Intermediate
-
-## Purpose
-
-Common TDD mistakes, rationalizations, and red flags to avoid. Learn to recognize when you're violating test-driven development principles.
-
-## Red Flags - Recognize and Stop
-
-### "I'll Write Tests After to Verify It Works"
-
-**What It Sounds Like:**
-- "Let me confirm this works first, then I'll test"
-- "I'll add tests once the feature is done"
-- "Tests are part of cleanup, I'll do them later"
-
-**Why It's Wrong:**
-- Tests passing immediately prove nothing
-- Didn't watch test fail = don't know if test works
-- Implementation may be hard to test (too late to redesign)
-- "Later" often becomes "never"
-
-**Reality Check:**
-```typescript
-// Test-after: Passes immediately
-test('validates email', () => {
-  expect(validateEmail('test@example.com')).toBe(true);
-});
-// ✓ PASS
-
-// But you never saw it fail!
-// Does it actually test anything? Unknown.
-```
-
-**What to Do Instead:**
-```typescript
-// Test-first: Watch it fail
-test('validates email', () => {
-  expect(validateEmail('test@example.com')).toBe(true);
-});
-// ✗ FAIL: validateEmail is not defined
-
-// Implement
-function validateEmail(email: string): boolean {
-  return email.includes('@');
-}
-
-// ✓ PASS: Now you know test works
-```
-
-### "Keep as Reference, Write Tests First"
-
-**What It Sounds Like:**
-- "I'll keep this code as a reference while writing tests"
-- "I'll adapt this implementation while test-driving"
-- "Let me look at what I built to write better tests"
-
-**Why It's Wrong:**
-- You WILL adapt existing code (human nature)
-- "Adapt" = testing after, not testing first
-- Reference biases your test design
-- Defeats purpose of TDD
-
-**Reality Check:**
-```typescript
-// You wrote this "reference":
-function processUser(user: any) {
-  const valid = user.email && user.age >= 18 && user.name;
-  if (!valid) throw new Error('Invalid');
-  return { id: generateId(), ...user };
-}
-
-// Now you write "test-first" while looking at it:
-test('processes valid user', () => {
-  const user = { email: 'test@example.com', age: 25, name: 'Test' };
-  const result = processUser(user);
-  expect(result.id).toBeDefined();
-});
-
-// You just tested what you built, not what it should do
-```
-
-**What to Do Instead:**
-```
-Delete the code. Seriously. Delete it.
-
-Then write test describing what SHOULD happen:
-test('creates user with required fields', () => {
-  const user = createUser({
-    email: 'test@example.com',
-    age: 25,
-    name: 'Test User'
-  });
-
-  expect(user).toMatchObject({
-    id: expect.any(String),
-    email: 'test@example.com',
-    age: 25,
-    name: 'Test User'
-  });
-});
-
-Now implement fresh from test.
-```
-
-### "Already Spent X Hours, Deleting Is Wasteful"
-
-**What It Sounds Like:**
-- "I can't throw away 4 hours of work"
-- "Let me just add tests to verify what I built"
-- "Rewriting would take too long"
-
-**Why It's Wrong:**
-- Sunk cost fallacy
-- Time already gone, can't recover it
-- Keeping unverified code = technical debt
-- Will spend more time debugging
-
-**Reality Check:**
-```
-Time spent: 4 hours
-Code quality: Unknown
-Test coverage: None
-Technical debt: High
-
-Option A: Keep it and test after
-Time: 4 hours (sunk) + 30 min (weak tests) + 120 min (future debugging)
-Total: 6.5 hours
-Quality: Low
-
-Option B: Delete and TDD
-Time: 4 hours (sunk) + 2 hours (TDD rewrite)
-Total: 6 hours
-Quality: High
-
-Option B is objectively better.
-```
-
-**What to Do Instead:**
-- Accept sunk cost
-- Treat it as learning time
-- Delete code
-- Rewrite with TDD (will be faster, you know the problem now)
-
-### "Tests After Achieve the Same Purpose"
-
-**What It Sounds Like:**
-- "I'll have 100% coverage either way"
-- "Tests-after verify correctness just as well"
-- "It's about the spirit, not the ritual"
-- "Being pragmatic means adapting"
-
-**Why It's Wrong:**
-- Coverage ≠ quality
-- Tests-after verify what you remembered
-- Can't achieve TDD spirit without TDD practice
-- Tests-after is optimistic gambling, not pragmatic
-
-**Reality Check:**
-```typescript
-// Test-after: 100% coverage, useless
-function add(a: number, b: number): number {
-  return a - b;  // BUG
-}
-
-test('add function', () => {
-  add(2, 3);  // 100% coverage!
-  // But doesn't verify result
-});
-
-// Test-first: Forces verification
-test('adds two numbers', () => {
-  expect(add(2, 3)).toBe(5);  // Must verify behavior
-});
-```
-
-See [Philosophy](philosophy.md) for detailed explanation.
-
-### "This Is Different Because..."
-
-**What It Sounds Like:**
-- "This is too simple for TDD"
-- "This is too complex for TDD"
-- "This is exploratory code"
-- "This is just a quick bug fix"
-- "This is legacy code (can't test)"
-
-**Why It's Wrong:**
-- Every situation has an excuse
-- All excuses are invalid
-- "Just this once" becomes "always"
-
-**Reality Check:**
-
-| Excuse | Truth |
-|--------|-------|
-| "Too simple" | Simple code breaks too |
-| "Too complex" | Complex code NEEDS tests |
-| "Exploratory" | Exploration teaches what to test |
-| "Quick fix" | Quick fixes need regression protection |
-| "Legacy code" | Characterization tests enable refactoring |
-
-**What to Do Instead:**
-- Stop rationalizing
-- Follow TDD process
-- Every. Single. Time.
-
-## Common Anti-Patterns
-
-### Pattern: Testing Implementation, Not Behavior
-
-**Bad:**
-```typescript
-test('uses regex to validate email', () => {
-  const validator = new EmailValidator();
-  expect(validator.pattern).toBe(/^[^\s@]+@[^\s@]+\.[^\s@]+$/);
-});
-```
-
-**Why Wrong:** Tests HOW, not WHAT. Prevents refactoring.
-
-**Good:**
-```typescript
-test('accepts valid email format', () => {
-  expect(validateEmail('user@example.com')).toBe(true);
-});
-
-test('rejects email without @ symbol', () => {
-  expect(validateEmail('userexample.com')).toBe(false);
-});
-```
-
-**Why Right:** Tests behavior. Implementation can change freely.
-
-### Pattern: Mocking Everything
-
-**Bad:**
-```typescript
-test('processes user data', () => {
-  const mockValidator = jest.fn().mockReturnValue(true);
-  const mockRepository = jest.fn().mockResolvedValue({ id: 1 });
-  const mockLogger = jest.fn();
-
-  const service = new UserService(mockValidator, mockRepository, mockLogger);
-
-  service.createUser({ name: 'Test' });
-
-  expect(mockValidator).toHaveBeenCalled();
-  expect(mockRepository).toHaveBeenCalled();
-  expect(mockLogger).toHaveBeenCalled();
-});
-```
-
-**Why Wrong:**
-- Tests mock interactions, not real code
-- Doesn't verify actual behavior
-- Brittle (breaks on implementation changes)
-
-**Good:**
-```typescript
-test('creates user with valid data', async () => {
-  const service = new UserService();
-
-  const user = await service.createUser({
-    name: 'Test User',
-    email: 'test@example.com'
-  });
-
-  expect(user.id).toBeDefined();
-  expect(user.name).toBe('Test User');
-  expect(user.email).toBe('test@example.com');
-});
-```
-
-**Why Right:** Tests real behavior using real objects.
-
-**When to Mock:** Only external dependencies you don't control (APIs, databases, file system).
-
-### Pattern: One Giant Test
-
-**Bad:**
-```typescript
-test('user registration flow', async () => {
-  // Test validates email
-  expect(validateEmail('test@example.com')).toBe(true);
-
-  // Test validates password
-  expect(validatePassword('Pass123')).toBe(true);
-
-  // Test creates user
-  const user = await createUser({...});
-  expect(user.id).toBeDefined();
-
-  // Test sends welcome email
-  expect(emailsSent).toContain('welcome');
-
-  // Test logs activity
-  expect(logs).toContain('user_created');
-});
-```
-
-**Why Wrong:**
-- Tests multiple behaviors
-- If fails, unclear what broke
-- Hard to understand what's being tested
-- Violates "one test, one behavior"
-
-**Good:**
-```typescript
-test('validates email format', () => {
-  expect(validateEmail('test@example.com')).toBe(true);
-});
-
-test('validates password strength', () => {
-  expect(validatePassword('Pass123')).toBe(true);
-});
-
-test('creates user with valid data', async () => {
-  const user = await createUser({...});
-  expect(user.id).toBeDefined();
-});
-
-test('sends welcome email after registration', async () => {
-  await createUser({...});
-  expect(emailsSent).toContain('welcome');
-});
-```
-
-**Why Right:** Each test has single, clear purpose.
-
-### Pattern: Vague Assertions
-
-**Bad:**
-```typescript
-test('processes array', () => {
-  const result = processArray([1, 2, 3]);
-  expect(result).toBeDefined();
-  expect(result.length).toBeGreaterThan(0);
-});
-```
-
-**Why Wrong:**
-- Doesn't verify actual behavior
-- Many wrong implementations would pass
-- Provides false confidence
-
-**Good:**
-```typescript
-test('doubles each element in array', () => {
-  const result = processArray([1, 2, 3]);
-  expect(result).toEqual([2, 4, 6]);
-});
-```
-
-**Why Right:** Precise assertion. Only correct implementation passes.
-
-### Pattern: Skipping Verification Steps
-
-**Bad:**
-```typescript
-// Write test
-test('retries on failure', async () => {
-  const result = await withRetry(operation);
-  expect(result).toBe('success');
-});
-
-// Implement immediately without running test
-async function withRetry(fn) {
-  try {
-    return await fn();
-  } catch (e) {
-    return await fn();
-  }
-}
-
-// Run both tests together
-// PASS: Both pass
-
-// You never saw test fail!
-```
-
-**Why Wrong:**
-- Don't know if test actually tests anything
-- Implementation might have already existed
-- Test might be broken
-
-**Good:**
-```typescript
-// Write test
-test('retries on failure', async () => {
-  const result = await withRetry(operation);
-  expect(result).toBe('success');
-});
-
-// MANDATORY: Run test FIRST
-// FAIL: withRetry is not defined
-// ✓ Good - test works
-
-// Implement
-async function withRetry(fn) {
-  try {
-    return await fn();
-  } catch (e) {
-    return await fn();
-  }
-}
-
-// Run test AGAIN
-// PASS
-// ✓ Good - implementation works
-```
-
-**Why Right:** Verified test fails, verified test passes. Confidence high.
-
-## Rationalization Detection
-
-### Self-Assessment Questions
-
-Ask yourself:
-
-**Before skipping RED phase:**
-- [ ] Am I making excuses?
-- [ ] Do I think "just this once"?
-- [ ] Am I under time pressure? (More reason for TDD!)
-- [ ] Do I feel the process is "too slow"? (It's faster overall)
-
-**After writing implementation first:**
-- [ ] Did I write code before test?
-- [ ] Am I now writing test to verify existing code?
-- [ ] Will my test pass immediately?
-- [ ] Did I watch the test fail first?
-
-**When reviewing tests:**
-- [ ] Did I watch each test fail before implementing?
-- [ ] Does each test verify behavior, not implementation?
-- [ ] Could I refactor without breaking tests?
-- [ ] Do tests use real code (not excessive mocks)?
-
-### If Any Answer Is "No"
-
-**STOP. You're not doing TDD.**
-
-Options:
-1. Delete implementation, start with test
-2. Admit you're not doing TDD, accept consequences
-3. Ask for help understanding how to TDD this
-
-## Recovery from Anti-Patterns
-
-### If You Wrote Code First
-
-**Option 1: Characterization Tests (if code works)**
-```typescript
-// Write tests for current behavior
-test('current behavior for case A', () => {
-  expect(existingFunction(inputA)).toBe(currentOutputA);
-});
-
-// Then refactor with test protection
-// Then delete and rewrite with TDD for new features
-```
-
-**Option 2: Delete and Restart (if code not verified)**
-```typescript
-// Delete implementation
-// Write failing test
-// Implement from test
-```
-
-### If Tests Are Too Broad
-
-**Refactor tests:**
-```typescript
-// Before: One giant test
-test('user registration', () => {
-  // 50 lines of test code
-});
-
-// After: Multiple focused tests
-describe('User Registration', () => {
-  test('validates email format', () => {...});
-  test('validates password strength', () => {...});
-  test('creates user record', () => {...});
-  test('sends welcome email', () => {...});
-});
-```
-
-### If Tests Are Brittle
-
-**Refactor to test behavior:**
-```typescript
-// Before: Tests implementation
-test('uses bcrypt with 10 rounds', () => {
-  expect(hasher.algorithm).toBe('bcrypt');
-  expect(hasher.rounds).toBe(10);
-});
-
-// After: Tests behavior
-test('hashes password securely', () => {
-  const hash1 = hashPassword('password');
-  const hash2 = hashPassword('password');
-
-  expect(hash1).not.toBe('password');  // Actually hashed
-  expect(hash1).not.toBe(hash2);       // Salted
-  expect(verifyPassword('password', hash1)).toBe(true);  // Verifiable
-});
-```
-
-## Summary
-
-**Red Flags:**
-- Code before test
-- Test passes immediately
-- "I'll test after"
-- "Keep as reference"
-- "Deleting is wasteful"
-- "Tests-after are equivalent"
-- "This is different because..."
-
-**Anti-Patterns:**
-- Testing implementation not behavior
-- Mocking everything
-- One giant test
-- Vague assertions
-- Skipping verification steps
-
-**Recovery:**
-- Recognize the anti-pattern
-- STOP immediately
-- Delete or refactor
-- Restart with proper TDD
-
-**Remember:** Proper TDD requires discipline but saves time. Shortcuts feel faster but waste time.
-
-## Related References
-
-- [Workflow](workflow.md): Correct TDD process
-- [Examples](examples.md): Real-world TDD practice
-- [Philosophy](philosophy.md): Why TDD works
-- [Integration](integration.md): TDD with other skills