test-driven-development

To start test-driven development, write a minimal behavior-focused test that fails for the expected missing-feature reason. Then, implement the minimal production code required to make that failing test pass, and finally refactor the code while ensuring the entire test suite stays green.

The red green refactor cycle is the core TDD workflow: red means writing a test that fails for the right reason, green means implementing minimal code to satisfy the test, and refactor means cleaning up the code without changing its behavior or breaking the test suite.

Write good unit tests by focusing on actual behavior rather than mock existence. Ensure tests are named clearly, watch them fail to verify they target the missing feature, and avoid adding test-only methods to your production code to prevent common testing anti-patterns.

Yes, you can apply a test-first workflow to bugfixes and refactoring. For a bugfix, write a failing test that reproduces the bug. For refactoring, rely on the existing passing test suite to verify that your structural changes do not alter the software's behavior.

Common test anti-patterns include testing mock behavior instead of real outcomes, adding test-only methods to production code, and skipping the watch it fail step. These practices lead to false confidence and obscure whether your unit tests actually verify the target behavior.