¿Separa las pruebas unitarias de sus pruebas de integración?

Question

Me preguntaba si alguien más simplemente ve las pruebas de integración como solo una prueba de unidad especial. Sin embargo, escuché de otros programadores que es una buena idea separar las pruebas unitarias y la prueba de integración. Me preguntaba si alguien podría explicar por qué esta 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. Yo opino que un solo paquete de prueba que contenga tanto pruebas unitarias como pruebas de integración sería suficiente ya que ambos son básicamente el mismo concepto.

Answer 1

los veo como diferente 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 deben realizarse en un entorno que se asemeje a la configuración de producción real.

Las pruebas de la unidad se mantienen deliberadamente "livianas" para que el desarrollador pueda ejecutarlas con la frecuencia necesaria con un costo mínimo.

Answer 2

Sip. Normalmente, las pruebas unitarias tienen un ámbito 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 sus tipos reales de ensamblaje.

Simplemente no veo cómo se podría organizar tanto la unidad y la integración en un solo proyecto.

Answer 3

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

Yo trabajo en un entorno en el que tenemos unos 15k pruebas JUnit con la unidad e integración de pruebas completamente mezclados. La suite completa tarda aproximadamente media hora en ejecutarse. Los desarrolladores evitan ejecutarlo y encontrar 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 construcción continua.

inicio separar sus pruebas antes de tiempo. Es muy difícil una vez que tienes una gran suite.

Answer 4

si se limita la noción de 'unidad de prueba' para alcance a nivel de clase, entonces sí, mantenerlos separados

Sin embargo, si se define la unidad más pequeña relevante comprobable como una característicaa continuación, algunos de sus pruebas de 'unidad' serán técnicamente 'integración' prueba

la rehashing de las diversas definiciones/interpretaciones de los términos es en gran medida irrelevante, sin embargo, partición de su suites de prueba debe ser una función del ámbito de aplicación de los componentes que se está 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 contra un único ensamblaje y se ejecutan en unos pocos segundos, entonces manténgalas juntas.Pero si algunas de sus pruebas requieren seis máquinas de instalación limpia en una subred, mientras que otras no, tiene sentido separar el primer conjunto de pruebas del último

resumen: la distinción de las pruebas de 'unidad' e 'integración' es irrelevante; paquetes de prueba de paquetes basados ​​en el alcance operativo