Respuesta.

Las pruebas automatizadas se dividen en unitarias (unit), de integración (integration) y de extremo a extremo (end-to-end, E2E) para cubrir de manera integral la verificación del sistema en diferentes niveles.

Historia de la pregunta: Esta clasificación surgió debido a la necesidad de probar aplicaciones tanto en partes como en su totalidad. Por lo tanto, se destacan las capas de pruebas:

• función específica (unit)
• interacción entre partes (integration)
• todo el sistema, funcionando como para el usuario (E2E)

Problema: Los errores a menudo ocurren no solo en la lógica de un método individual, sino también en las interfaces entre componentes o al ejecutar todo el sistema con servicios externos. Si se agrupan todo en un solo conjunto, es difícil localizar rápidamente un error o entender dónde exactamente se originó.

Solución:

• Las pruebas unitarias verifican código aislado, generalmente a nivel de funciones o clases simples. En casos avanzados, se utilizan mocks y stubs.
• Las pruebas de integración conectan varios componentes (por ejemplo, un módulo y una base de datos) para ver cómo funcionan juntos.
• Las pruebas de extremo a extremo (E2E) simulan escenarios de usuario: todo el camino "desde el botón hasta el resultado".

Distinguir los tipos de pruebas es vital para:

1. Minimizar el costo de mantenimiento (las pruebas E2E son caras)
2. Mantener una respuesta rápida (las pruebas unitarias son relámpago)
3. Reducir la cantidad de falsos positivos

Características clave:

• La correcta distribución de las pruebas ayuda a construir un enfoque "piramidal" confiable (pirámide de pruebas).
• La mezcla de estilos de prueba conduce a problemas de localización de errores.
• Una clara comprensión del propósito de cada capa lleva a la máxima eficiencia.

Preguntas capciosas.

¿Se pueden considerar las pruebas de integración como "grandes" pruebas unitarias?

No, las pruebas de integración prueban el funcionamiento de varios componentes juntos, no solo funciones individuales. Además, no siempre es posible utilizar mocks: los servicios reales interactúan entre sí.

¿Deben ser todas las pruebas de extremo a extremo (E2E)?

No, este es un enfoque costoso y complicado. Las E2E son necesarias solo para escenarios críticos del usuario; la mayor parte de la lógica se cubre con otras pruebas.

¿Las pruebas unitarias siempre son rápidas?

No siempre. A veces, no es posible aislar el código o un método depende de recursos externos complejos. En tal caso, la prueba deja de ser unitaria.

Errores comunes y antipatrón

• Todas las pruebas se realizan solo como E2E, lo que resulta en un feedback extremadamente lento.
• Confusión en las capas: una prueba unitaria comienza a llamar a la base de datos o API, mientras que las E2E se construyen sobre mocks.
• Dejan solo pruebas unitarias: los errores problemáticos en las interfaces de los componentes no se detectan.

Ejemplo de la vida real

Caso negativo

En la empresa, solo cubrieron la funcionalidad principal con pruebas E2E: cada corrección se verificaba por la noche, las pruebas fallaban de manera inestable, y los errores se detectaban tarde.

Ventajas:

• Se cubrieron escenarios reales de usuario.

Desventajas:

• Feedback lento.
• Largas discusiones sobre las causas de las fallas.
• Muchos falsos positivos.

Caso positivo

El equipo construyó una pirámide de pruebas: en la parte inferior — pruebas unitarias, en el medio — pruebas de integración, y en la parte superior — solo las pruebas E2E más importantes.

Ventajas:

• Rápidamente se ve dónde se rompió el código.
• El mantenimiento de las pruebas es más sencillo.

Desventajas:

• Se requiere buena disciplina al separar las capas.