Al estudiar desarrollo, hay un obstáculo inevitable.
«Pruebas unitarias, de integración, UI… ¿qué diferencia hay?»
Empecemos por la conclusión.
Las tres pruebas cubren distintos ámbitos. La unitaria verifica una función, la de integración conecta módulos y la de UI comprueba toda la pantalla del usuario.
La «pirámide de pruebas» indica en qué proporción combinar las tres. Hoy explicaré el concepto con ejemplos de mi experiencia.
Veamos primero el resumen clave
Para quienes tienen prisa, aquí va el resumen.
- Prueba unitaria: verifica una función o clase. Es rápida y se escribe en cantidad.
- Prueba de integración: comprueba que varios módulos funcionen al conectarse. Cantidad intermedia.
- Prueba de UI: valida todo el flujo como si se hiciera clic en la pantalla real. Es lenta y escasa.
- Pirámide de pruebas: principio de construir una base amplia de pruebas unitarias y una cima estrecha de UI.
Con recordar estas cuatro líneas ya entenderán la mitad. Ahora veremos cada punto.
Pruebas unitarias, de integración y de UI: ¿qué diferencia hay?
Como es la parte más confusa, empezaré con una analogía.
Imaginemos que construimos un automóvil.
La prueba unitaria comprueba si un tornillo cumple la especificación. Es una unidad muy pequeña.
La prueba de integración verifica que el motor y la transmisión encajen y funcionen al conectarlos.
La prueba de UI consiste en subir al automóvil terminado, arrancarlo y conducirlo.
En una tabla, la comparación queda así.
| Categoría | Ámbito de verificación | Velocidad | Cantidad escrita |
|---|---|---|---|
| Prueba unitaria | Una función o clase | Muy rápida (ms) | Mucha |
| Prueba de integración | Interacción entre módulos | Normal (en segundos) | Intermedia |
| Prueba de UI | Todo el flujo del usuario | Lenta (decenas de segundos) | Poca |
La diferencia clave es «qué tan amplio es el alcance».
Cuanto más amplio es el alcance, más se parece al entorno real, pero también es más lento y difícil de mantener.
Así se sienten las pruebas unitarias
Las palabras no bastan, así que veamos un ejemplo breve.
Este es un prueba unitaria que verifica únicamente una función que suma dos números.
// Prueba unitaria que verifica una sola función de suma
func add(_ a: Int, _ b: Int) -> Int {
return a + b
}
@Test func Suma_2_adición_3es_5() {
#expect(add(2, 3) == 5)
}Como ven, no hacen falta una base de datos externa ni una pantalla. Aislamos y comprobamos una sola función.
Por eso termina en un abrir y cerrar de ojos. Incluso cientos de pruebas tardan solo unos segundos.
Por eso uso más las pruebas unitarias: puedo corregir el código y comprobarlo al instante.
¿Qué es la pirámide de pruebas?
Ahora llega la protagonista de hoy: la pirámide de pruebas.
Es un concepto que Mike Cohn presentó en 2009 en su libro 『Succeeding with Agile』. Propone apilar las pruebas formando un triángulo.
- Parte inferior (ancha): pruebas unitarias — la mayoría
- Parte central: pruebas de integración — una cantidad moderada
- Parte superior (estrecha): pruebas de UI — las mínimas
¿Por qué tiene esta forma?
Porque las pruebas son más rápidas y baratas cuanto más abajo están. Ejecutar miles de pruebas unitarias no supone una carga importante.
En cambio, las pruebas de UI son lentas y se rompen fácilmente con pequeños cambios visuales. Su mantenimiento cuesta mucho.
Muchas pruebas baratas y rápidas; pocas pruebas caras y lentas. Eso es toda la pirámide de pruebas.
Si se invierte la pirámide, se llama antipatrón «cono de helado». Hay muchas pruebas de UI y ninguna unitaria: pruebas lentas y frágiles que dificultan el trabajo.
Entonces, ¿qué proporción usamos?
Es una cuestión que muchos se plantean.
La referencia más citada es aproximadamente 70 % unitarias : 20 % de integración : 10 % de UI.
Pero no es una regla absoluta. Hay que ajustarla según el proyecto.
En un servidor API de backend, por ejemplo, conviene aumentar el peso de las pruebas de integración. Incluso Google suele destacar mantener la forma de pirámide, más que un número exacto.
Permítanme añadir un consejo de mi propia experiencia.
No se obsesionen con las cifras. Lo importante es revisar habitualmente si dependen demasiado de pruebas lentas y frágiles.
Preguntas frecuentes (Q&A)
P. ¿Las pruebas E2E y las pruebas de UI son lo mismo?
Se usan de forma casi equivalente, pero técnicamente difieren. E2E (End-to-End) valida todo el flujo desde la perspectiva del usuario; las pruebas de UI se centran en manipular la pantalla. En la práctica, suelen mezclarse.
P. Si hago bien las pruebas de integración, ¿puedo prescindir de las unitarias?
No es recomendable. Con una prueba de integración es difícil localizar el origen del problema. Las unitarias permiten acotarlo rápidamente.
P. ¿Hay que escribir todas las pruebas desde el principio?
No. Recomiendo empezar por pruebas unitarias de la lógica principal. He visto a muchos agotarse intentando construir una pirámide perfecta desde el primer día.
La diferencia entre las tres puede parecer abstracta al leerla, pero se entiende de verdad al escribir código.
Empiecen añadiendo una prueba unitaria a una función pequeña. Al acumular esa práctica, lo demás llegará de forma natural. ¡Mucho ánimo!