¿Separas tus pruebas unitarias de tus pruebas de integración? [cerrado]

Question

Me preguntaba si alguien más solo vería las pruebas de integración como una prueba unitaria especial. Sin embargo, he escuchado de otros programadores que es una buena idea separar las pruebas de unidad y la prueba de integración. Me preguntaba si alguien podría explicar por qué es una buena idea. ¿Qué tipo de ventajas habría para tratar la integración y las pruebas unitarias como completamente diferentes? Por ejemplo, he visto carpetas y paquetes separados para pruebas de integración y pruebas unitarias. Sería de la opinión de que un solo paquete de prueba que contenga pruebas unitarias y pruebas de integración sería suficiente, ya que ambos son básicamente el mismo concepto.

Answer 1

Los veo como diferentes por la siguiente razón.

• Las pruebas unitarias se pueden realizar en una sola clase / módulo en el entorno del desarrollador.
• Las pruebas de integración se deben realizar en un entorno que se asemeja a la configuración de producción real.

Las pruebas unitarias se mantienen deliberadamente " ligeras " para que el desarrollador pueda ejecutarlas con la frecuencia que sea necesaria con un costo mínimo.

Answer 2

La velocidad es la razón principal. Desea que las pruebas unitarias sean lo más rápidas posible para que pueda ejecutarlas con la mayor frecuencia posible. Aún debe ejecutar sus pruebas de integración, pero ejecutarlas una vez antes de un check-in debería ser suficiente IMO. El conjunto de pruebas unitarias debe ejecutarse con mucha más frecuencia, idealmente con cada refactorización.

Trabajo en un entorno en el que tenemos aproximadamente 15.000 pruebas Junit con pruebas unitarias y de integración completamente mezcladas. La suite completa tarda aproximadamente media hora en ejecutarse. Los desarrolladores evitan ejecutarlo y encuentran errores más tarde de lo que deberían. A veces se registran después de ejecutar solo un subconjunto de las pruebas e incluyen un error que rompe la compilación continua.

Comience a separar sus pruebas temprano. Es muy difícil una vez que tienes una suite grande.

Answer 3

Sí. Normalmente, las pruebas unitarias tienen un alcance a nivel de clase, por lo que existen en un entorno junto con objetos simulados. Las pruebas de integración, por otro lado, hacen todos los trucos manteniendo las referencias a los tipos de ensamblaje real .

Simplemente no veo cómo se organizarían tanto la unidad como la integración en un solo proyecto.

Answer 4

Si limita la noción de 'prueba de unidad' al alcance en el nivel de clase, entonces sí, manténgalos separados

sin embargo, si define la unidad verificable relevante más pequeña como una función , algunas de sus pruebas de 'unidad' serán técnicamente pruebas de 'integración'

la repetición de las diversas definiciones / interpretaciones de los términos es en gran medida irrelevante, sin embargo, la partición de sus suites de prueba debe ser una función del alcance de los componentes que se están probando y el tiempo requerido para realizar la prueba.

Por ejemplo, si todas sus pruebas (unidad, integración, regresión o lo que sea) se aplican en un solo ensamblaje y se ejecutan en unos segundos, entonces manténgalas todas juntas. Pero si algunas de sus pruebas requieren seis máquinas de instalación limpias en una subred, mientras que otras no, tiene sentido separar el primer conjunto de pruebas de la última

resumen: la distinción entre pruebas de 'unidad' e 'integración' es irrelevante; paquetes de prueba de paquetes basados ??en el alcance operacional