TestDrivenDevelopment

Test-driven development enforces writing a failing test before any production code, following the red-green-refactor cycle. Write a test that fails, implement minimal code to pass it, then refactor while tests remain green. This discipline ensures every line of production code has test coverage and satisfies the core requirement: no production code without a failing test first.

Red-green-refactor is the TDD workflow: write a failing test (red), implement minimal code to pass it (green), then improve the code without breaking tests (refactor). This cycle prevents untested code, catches bugs early, and maintains a safety net as you evolve the codebase across any language or framework.

Yes. Write a failing test that reproduces the bug, verify the test fails, then implement the fix to make it pass. This approach ensures the bug is actually fixed and prevents regression, as the test becomes permanent coverage for that specific issue.

Begin the red phase: write a failing test that describes the feature's expected behavior in your language and framework. Run it to confirm failure, then implement the minimal code needed to pass. Finally, refactor for clarity while keeping tests green throughout.

Yes. TDD is language-agnostic and framework-independent. The red-green-refactor discipline applies whether you're working with Java, Python, JavaScript, Go, or any other language; the core principle—no production code without a failing test—remains constant.

You violate TDD's iron law and lose its quality guarantees. Code written without a failing test lacks immediate test coverage, increases the risk of untested edge cases, and breaks the discipline that ensures every feature and fix is validated before deployment.