test-driven-development

Test-driven development starts by writing a failing unit test for the desired behavior first. Write a minimal test that describes what the feature should do, watch it fail (red phase), then implement only the code needed to pass it (green phase), and finally refactor for clarity while keeping tests passing.

Red-green-refactor is a TDD cycle: write a failing test (red), implement minimal code to pass it (green), then improve the code without changing behavior (refactor). This ensures each piece of production code is validated by a focused test before it ships.

Apply TDD to bug fixes by first writing a test that reproduces the bug and fails on current code, then fix the bug with minimal changes to make the test pass. This prevents regression and documents the expected behavior.

Yes. TDD applies across test levels—use unit tests for isolated components, integration tests for component interactions, and end-to-end tests for full workflows. Run only the relevant test subset for each change to keep feedback fast.

Write tests that focus on one behavior each with descriptive names that explain the scenario. Avoid testing implementation details; test observable outcomes. This keeps the test suite maintainable and clarifies intent for future developers.

After passing tests (green phase), run lint and type checkers to catch code-quality issues before production. This ensures your implementation is not only functionally correct but also adheres to style and type safety standards.