testing - sistema - tipos de pruebas de software
Pruebas: unidad vs. integración vs. otros, ¿cuál es la necesidad de separación? (3)
Definiciones de mi mundo:
Prueba de unidad: prueba las rutas obvias del código y proporciona los resultados esperados.
Prueba de función: examina a fondo las definiciones del software y prueba 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 mismo. 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.
A la pregunta ¿Estoy probando la unidad o las pruebas de integración? He respondido, un poco provocativo: haga su prueba y permita que otras personas pasen tiempo con la taxonomía .
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 las fallas del 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 rechazada o fuertemente 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 distintos niveles de prueba es o no relevante.
¿Está equivocada mi opinión? ¿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 : soy perfectamente consciente de las definiciones (para los que no lo son, vea esta pregunta ). Creo que no necesito una lección sobre pruebas de software. Pero no dude en proporcionar algunos antecedentes si su respuesta lo requiere.
El rendimiento suele ser la razón por la que segrego las pruebas de "unidad" de las pruebas "funcionales".
Los grupos de pruebas unitarias 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 día por medio dependiendo de la función que se implemente.
Si todas las pruebas estuvieran agrupadas, nunca haría ninguna prueba hasta justo antes de registrarme, lo que ralentizaría mi ritmo general de desarrollo.
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 de 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).
Sin embargo, sobre todo, diría que es mejor ser pragmático y no dogmático al respecto, pero reconozca las diferencias y evite entremezclas si sus pruebas de integración hacen que sea muy costoso realizar sus pruebas con frecuencia.