Glosario · Fundamentos de testing
Pirámide de pruebas
En inglés: Test pyramid
También llamado: pirámide de testing, pirámide de automatización de pruebas, testing pyramid, pirámide de tests
Definición
Modelo para equilibrar una suite automatizada: muchos tests unitarios rápidos en la base, menos tests de integración encima y pocos tests end-to-end en la cima.
La pirámide de pruebas (test pyramid) es una guía para repartir los tests automatizados entre niveles. La base ancha son los tests unitarios, que son rápidos, baratos y precisos. El centro son los tests de integración o de servicio. La cima estrecha son los tests end-to-end a través de la UI, que dan la confianza más realista pero son los más lentos y frágiles. La idea, popularizada por Mike Cohn, es bajar cada comprobación al nivel más bajo capaz de detectar el problema.
Ejemplo
Toma una regla: “los pedidos de más de 100 $ tienen envío gratis”.
- Unitario: prueba la función del coste de envío con 99,99 $, 100,00 $ y 100,01 $. Milisegundos cada uno, sin navegador.
- Integración/API: llama a
POST /orderscon un carrito de 120 $ y comprueba que la respuesta tieneshipping: 0. Esto demuestra que la regla está conectada al servicio. - End-to-end: un único test de UI que completa la compra de un carrito que cumple la condición y ve “Free shipping” en la página de confirmación.
No necesitas diez tests de UI para los valores límite. Los tests unitarios ya demuestran la aritmética.
Por qué importa la forma
Los tests de nivel más alto tocan más componentes, así que un fallo te dice menos sobre dónde está el bug. Además, necesitan navegadores, entornos y datos de prueba, lo que los hace más lentos y más propensos a ser flaky. Una suite compuesta sobre todo por tests de UI (el antipatrón del “cono de helado”) tarda horas, falla por motivos ajenos al cambio y acaba ignorada.
Críticas y alternativas
La pirámide es una heurística, no una cuota. Alternativas como el “testing trophy” dan más peso a los tests de integración, con el argumento de que los tests unitarios con muchos mocks pueden pasar mientras el sistema real está roto. Ambos modelos coinciden en lo importante: mantener pocos tests de UI lentos y amplios, centrados en los recorridos críticos, y obtener la mayor parte de la confianza de las capas más rápidas. Elige el equilibrio según de dónde vienen realmente tus bugs, no según una proporción fija.