¿Qué es Test-Driven Development (TDD)?

Question

Accepted Answer

**Test-Driven Development (TDD)** es una práctica en la que **escribes pruebas antes del código** — siguiendo un ciclo corto y repetitivo: escribir una prueba fallida, escribir código para pasarla, luego refactorizar. Impulsa el diseño a través de pruebas y garantiza que el código sea comprobable y esté bien probado.

## El ciclo TDD: Red, Green, Refactor

```text
1. RED → write a FAILING test for the behavior you want (it fails — the code doesn't exist yet)
2. GREEN → write the MINIMUM code to make the test PASS (just enough, don't over-build)
3. REFACTOR → improve/clean up the code (and tests) while keeping tests GREEN
→ Repeat this short cycle for each small piece of behavior.
```

```text
Write test (RED) → write code (GREEN) → clean up (REFACTOR) → repeat
```

## Flujo de ejemplo

```js
// 1. RED — write the test first (fails: add doesn't exist / is wrong)
test('add(2,3) === 5', () => expect(add(2, 3)).toBe(5));

// 2. GREEN — write minimal code to pass
function add(a, b) { return a + b; }

// 3. REFACTOR — improve if needed (test still passes); then write the next test
```

## Beneficios y consideraciones

```text
✓ Ensures code is TESTABLE (you design for testing) and TESTED (tests exist by definition)
✓ Drives DESIGN — thinking about behavior/interface first → cleaner, focused code
✓ Fast FEEDBACK; confidence to refactor; avoids over-engineering (write only what's needed)
✓ Good test coverage as a natural result
⚠️ A discipline/skill that takes practice; not always applied dogmatically (use judgment)
```

## Por qué es importante

Entender Test-Driven Development es valioso porque es una **práctica influyente y ampliamente discutida** que moldea cómo muchos desarrolladores abordan las pruebas y el diseño, por lo que es un conocimiento importante para el desarrollo profesional.

La idea central de TDD — **escribir pruebas antes del código**, siguiendo el **ciclo Red-Green-Refactor** (escribir una prueba fallida, escribir código mínimo para pasarla, luego refactorizar manteniendo las pruebas verdes) — es un enfoque distintivo que invierte el orden habitual.

Entender el ciclo es el conocimiento práctico clave.

Entender los **beneficios** explica por qué TDD es valorado: garantiza que el código sea **comprobable** (diseñando para las pruebas desde el inicio) y **probado** (las pruebas existen por definición), **impulsa el diseño** (pensar en el comportamiento e interfaz primero lleva a código más limpio y enfocado), proporciona retroalimentación rápida y confianza para refactorizar, evita sobre-ingeniería (escribiendo solo lo necesario para pasar pruebas), y produce naturalmente una buena cobertura de pruebas.

Estos beneficios hacen que TDD sea influyente tanto como práctica de pruebas como de diseño.

Entender las **consideraciones** — que TDD es una disciplina que requiere práctica, y que no siempre se aplica dogmáticamente (los desarrolladores usan criterio sobre cuándo se ajusta) — refleja una visión equilibrada y realista.

Incluso los desarrolladores que no siempre practican TDD se benefician de entenderlo, ya que moldea el pensamiento sobre pruebas y diseño y es un tema común en desarrollo profesional e entrevistas.

Como TDD es una práctica influyente y ampliamente conocida que moldea los enfoques de pruebas y diseño (con beneficios reales en comprobabilidad, diseño y cobertura) y es un tema profesional y de entrevista común, y como entender el ciclo, beneficios y consideraciones refleja madurez en pruebas, entender Test-Driven Development es un conocimiento valioso y relevante — una práctica y filosofía de pruebas importante que vale la pena entender para desarrollo profesional, influyente en cómo los desarrolladores orientados a la calidad abordan la construcción de software.