tdd

Test-Driven Development (TDD) enforces a Red-Green-Refactor cycle where you write a failing test first, implement minimal code to pass it, then refactor safely. This ensures all new features and bug fixes have test coverage before production code exists.

To start Test-Driven Development, write a failing test that defines the missing functionality before writing any production code. Then create the minimal code required to make that test pass, followed by refactoring the implementation while keeping tests green.

Yes, Test-Driven Development supports applying the Red-Green-Refactor workflow to both pure logic like store actions and React components. It provides specific examples demonstrating how to write failing tests first for these component types within the HACER project.

Test-Driven Development integrates with Vitest to guide the testing workflow. You write failing Vitest tests first, implement minimal production code to pass them, and then refactor while maintaining code quality and verifying results through the test suite.

The best way to ensure code quality is enforcing Test-Driven Development. By writing a failing test before any production code, you verify the exact requirement upfront, implement minimal logic to pass, and refactor safely with continuous test validation.

Test-Driven Development is designed for new features and bug fixes where you can define expected behavior through a failing test. It is not suited for exploratory spikes or trivial configuration changes where writing a failing test first adds overhead without clear behavioral validation.