Skip to content

Latest commit

 

History

History
167 lines (119 loc) · 3.25 KB

File metadata and controls

167 lines (119 loc) · 3.25 KB
domain archive
title Test Driven Development
verification metadata-normalized
source skill-pipeline
status draft
created 2026-05-09

背景

(此 lesson 从 skill test-driven-development 自动提取,待补全)

根因

(待补充)

修复

Test-Driven Development (TDD)

Overview

Write the test first. Watch it fail. Write minimal code to pass.

Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.

Violating the letter of the rules is violating the spirit of the rules.

When to Use

Always:

  • New features
  • Bug fixes
  • Refactoring
  • Behavior changes

Exceptions (ask the user first):

  • Throwaway prototypes
  • Generated code
  • Configuration files

Thinking "skip TDD just this once"? Stop. That's rationalization.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Write code before the test? Delete it. Start over.

No exceptions:

  • Don't keep it as "reference"
  • Don't "adapt" it while writing tests
  • Don't look at it
  • Delete means delete

Implement fresh from tests. Period.

Red-Green-Refactor Cycle

RED — Write Failing Test

Write one minimal test showing what should happen.

Good test:

def test_retries_failed_operations_3_times():
    attempts = 0
    def operation():
        nonlocal attempts
        attempts += 1
        if attempts < 3:
            raise Exception('fail')
        return 'success'

    result = retry_operation(operation)

    assert result == 'success'
    assert attempts == 3

Clear name, tests real behavior, one thing.

Bad test:

def test_retry_works():
    mock = MagicMock()
    mock.side_effect = [Exception(), Exception(), 'success']
    result = retry_operation(mock)
    assert result == 'success'  # What about retry count? Timing?

Vague name, tests mock not real code.

Requirements:

  • One behavior per test
  • Clear descriptive name ("and" in name? Split it)
  • Real code, not mocks (unless truly unavoidable)
  • Name describes behavior, not implementation

Verify RED — Watch It Fail

MANDATORY. Never skip.

# Use terminal tool to run the specific test
pytest tests/test_feature.py::test_specific_behavior -v

Confirm:

  • Test fails (not errors from typos)
  • Failure message is expected
  • Fails because the feature is missing

Test passes immediately? You're testing existing behavior. Fix the test.

Test errors? Fix the error, re-run until it fails correctly.

GREEN — Minimal Code

Write the simplest code to pass the test. Nothing more.

Good:

def add(a, b):
    return a + b  # Nothing extra

Bad:

def add(a, b):
    result = a + b
    logging.info(f"Adding {a} + {b} = {result}")  # Extra!
    return result

Don't add features, refactor other code, or "improve" beyond the test.

Cheating is OK in GREEN:

  • Hardcode return values
  • Copy-paste
  • Duplicate code
  • Skip edge cases

We'll fix it in REFACTOR.

Verify GREEN — Watch It Pass

MANDATORY.

# Run the specific test
pytest tests/test_feature.py::test_specific_behavior -v

# Then run ALL tests to check for regressions
pytest tests/ -q

Confirm:

  • Test passes
  • Other tests still pass
  • Output p

验证

(待补充)