¿Por qué una pirámide?
No todas las pruebas cuestan lo mismo ni dan la misma confianza. La pirámide de testing (Mike Cohn) es una heurística para repartir el esfuerzo: ancha en la base, estrecha en la cima.
/\ E2E ← pocos: lentos, frágiles, alta confianza
/ \
/----\ Integración ← algunos: varias piezas juntas
/ \
/--------\ Unit ← muchos: rápidos, baratos, aislados
Las tres capas
- Unit (base, mayoría): prueban una unidad aislada (una función, una clase) sin tocar red, disco ni base de datos. Se ejecutan en milisegundos, así que puedes tener miles y correrlos en cada guardado. Cuando fallan, señalan con precisión qué se rompió.
- Integración (medio): comprueban que varias piezas colaboran bien: un endpoint con su capa de datos, un componente con su store. Más lentos que los unit, pero detectan errores que los unit no ven (contratos entre módulos).
- E2E (cima, minoría): ejercitan toda la aplicación como un usuario real, desde el navegador hasta la base de datos. Dan la mayor confianza ("esto funciona de verdad") pero son lentos y frágiles.
El eje coste / velocidad / confianza
Conforme subes en la pirámide, cada prueba cubre más sistema (más confianza de que el producto funciona) pero a cambio es más lenta, más cara de escribir y más propensa a fallar por motivos ajenos al bug (timing, red, datos). Por eso quieres muchos tests baratos abajo y pocos caros arriba: máxima confianza por minuto de ejecución.
Antipatrón: el cono de helado (muchos E2E, pocos unit). La suite tarda horas, falla de forma intermitente y nadie confía en ella.
Ejemplos
Un test unitario: rápido y aislado
function precioConIva(neto, iva) {
return Math.round(neto * (1 + iva) * 100) / 100;
}
// El "test" comprueba una sola unidad, sin red ni BD:
console.log(precioConIva(100, 0.21) === 121 ? "OK" : "FALLA");