Prueba: unidad vs. integración vs. otros, ¿cuál es la necesidad de separación?

Question

A la pregunta Am I unit testing or integration testing? He respondido, un poco provocativo: Do your test and let other people spend time with taxonomy.

Para mí, la distinción entre varios niveles de prueba es técnicamente inútil: a menudo se usan las mismas herramientas, se necesitan las mismas habilidades, se debe alcanzar el mismo objetivo: eliminar fallas de software. Al mismo tiempo, puedo entender que los flujos de trabajo tradicionales, que la mayoría de los desarrolladores usan, necesitan esta distinción. Simplemente no me siento a gusto con los flujos de trabajo tradicionales.

Pensé que mi respuesta sería fuertemente negativa o altamente votada. De hecho ambos ocurrieron, con cinco upvotes y cuatro downvotes. Incluso el primer comentario fue un poco vacilante (¡gracias por tu voto positivo por cierto!).

Por lo tanto, mi pregunta tiene como objetivo comprender mejor lo que me parece una controversia y reunir varios puntos de vista sobre si esta separación entre los diferentes niveles de prueba es relevante o no.

¿Mi opinión es incorrecta? ¿Existen otros flujos de trabajo que no enfatizan en esta separación (tal vez métodos ágiles)? ¿Cuál es su experiencia sobre el tema?

Precisión: Estoy perfectamente al tanto de las definiciones (para los que no, vea this question). Creo que no necesito una lección sobre pruebas de software. Pero no dude en proporcionar algunos antecedentes si su respuesta lo requiere.

Answer 1

El rendimiento suele ser la razón por la que segrego las pruebas de "unidad" de las pruebas "funcionales".

Las pruebas de grupos de unidades deben ejecutarse lo más rápido posible y poder ejecutarse después de cada compilación.

Los grupos de pruebas funcionales pueden tardar unos minutos en ejecutarse y ejecutarse antes de registrarse, tal vez todos los días o cada dos días dependiendo de la función que se implemente.

Si todas las pruebas se agrupan juntas, nunca realizaría ninguna prueba hasta justo antes del checkin, lo que ralentizaría mi ritmo general de desarrollo.

Answer 2

Definiciones de mi mundo:

prueba de unidad - a prueba los caminos obvios del código y que producen los resultados esperados.

Prueba de funcionamiento: examinar a fondo las definiciones del software y probar cada ruta definida, a través de todos los rangos permitidos. Un buen momento para escribir pruebas de regresión.

Prueba del sistema: prueba el software en su entorno de sistema, en relación con él. Genere todos los procesos que pueda, explore cada combinación interna, ejecútelo un millón de veces durante la noche, vea qué se cae.

Prueba de integración: ejecútela en una configuración de sistema típica y vea si otro software causa un conflicto con el probado.

Answer 3

Tendría que estar de acuerdo con @Alex B en que necesita diferenciar entre pruebas unitarias y pruebas de integración al escribir sus pruebas para hacer que sus pruebas unitarias se ejecuten lo más rápido posible y no tener más dependencias que las requeridas para probar el código bajo prueba. Desea que las pruebas unitarias se ejecuten con mucha frecuencia y, cuanto más "integradas" sean, menos se ejecutarán.

Para facilitar esto, las pruebas unitarias generalmente (o deberían) implican burlas o falsas dependencias externas. Las pruebas de integración dejan intencionalmente estas dependencias porque ese es el punto de la prueba de integración. ¿Necesitas burlar/fingir cada dependencia externa? Yo diría que no necesariamente si el costo de burlarse/fingir es alto y el valor devuelto es bajo, es decir, el uso de la dependencia no aumenta significativamente el tiempo o la complejidad de la (s) prueba (s).

Aunque, sobre todo, diría que es mejor ser pragmático en lugar de dogmático al respecto, pero reconozca las diferencias y evite entremezclas si sus pruebas de integración hacen que sea demasiado caro ejecutar sus pruebas con frecuencia.