Estrategia de Testing

Nivel intermedio — diseñar una estrategia de testing balanceada siguiendo la pirámide de pruebas de Mike Cohn.

Idea central Más tests no es mejor. Una estrategia balanceada maximiza confianza en el código con el mínimo coste de mantenimiento — los tests correctos en la capa correcta valen más que cobertura alta mal distribuida.

01 —

El problema

Los equipos caen en dos extremos: cero tests ("no hay tiempo") o tests por todos lados sin estrategia (100% de cobertura inútil).

Situación típica: el equipo tiene 500 tests E2E. Tardan 45 minutos en correr. Fallan aleatoriamente por timeouts. Nadie confía en ellos — los developers los ignoran y hacen merge cuando "la mayoría" pasa. Un bug obvio llega a producción porque el test unitario que lo habría atrapado nunca se escribió. // una suite enorme puede dar menos confianza que una bien distribuida

02 —

La pirámide de pruebas (Mike Cohn)

E2EPocos (10%) · minutos · alto coste
Validan flujos críticos

IntegrationModerados (20%) · segundos · coste medio
Validan integración de componentes

UnitMuchos (70%) · milisegundos · bajo coste
Validan lógica aislada

03 —

Qué testear en cada capa

Unit tests

✓ Buenos candidatos: funciones puras, validaciones, cálculos, transformaciones de datos, lógica de dominio
✗ No vale la pena: getters/setters simples, código que solo llama a otro código, configuración

Integration tests

✓ Buenos candidatos: API endpoints con base de datos, servicios que llaman a otros servicios, queries complejas, flujos de autenticación
✗ No vale la pena: cada endpoint CRUD simple, validaciones ya cubiertas por unit tests

E2E tests

✓ Buenos candidatos: happy path de flujos críticos de negocio, compra/pago, signup/login, operaciones que no puedes permitir que fallen
✗ No vale la pena: cada variación de un flujo, edge cases (mejor en unit/integration), detalles de UI que cambian frecuentemente

Cobertura alta ≠ confianza alta

El caso de los 500 tests E2E de esta lección tenía, seguramente, "buena cobertura" en número — y aun así el equipo no confiaba en la suite. El dato que importa no es cuántos tests hay, sino en qué capa están: 100% de cobertura toda en E2E es peor que 70% bien distribuido según la pirámide, porque es lenta, frágil, y esconde justo los bugs de lógica que un unit test habría atrapado en milisegundos.

04 —

Practica: los 3 niveles sobre el Walking Skeleton

Agrega los tres niveles de tests al Walking Skeleton de la Lección 5.1: un unit test para una función de validación pura (ej. validateTodoTitle), un integration test para el endpoint conectado a PostgreSQL, y un E2E test para el flujo completo de crear una tarea desde la UI.