test-driven-development

Write a test that reproduces the bug first and confirm it fails, then implement the fix and confirm the test passes. This Prove-It Pattern guarantees the bug actually existed and the fix actually resolves it, while permanently guarding against regression.

Inspect the project's build files like package.json, pom.xml, pyproject.toml, go.mod, or Cargo.toml, and prefer checked-in wrappers like ./gradlew or make test. README, CONTRIBUTING, and CI workflows show the commands that actually gate merges.

Prefer real implementations first, then fakes, stubs, and mocks last. Mock only when the real dependency is too slow, non-deterministic, or has uncontrollable side effects like external APIs, since over-mocking creates tests that pass while production breaks.

Skip TDD for pure configuration changes, documentation updates, or static content with no behavioral impact. Any change affecting logic, behavior, or edge cases should begin with a failing test.

A test that passes on the first run proves nothing — it may not exercise the intended behavior at all. The RED step of TDD exists specifically to confirm the test actually fails before the implementation exists, validating the test itself.