unit-testing - test - tipos de pruebas unitarias
¿Separa las pruebas unitarias de sus pruebas de integración? (4)
Me preguntaba si alguien más 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.
La 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.
Trabajo en un entorno en el que tenemos aproximadamente 15k 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 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.
Comience a separar sus exámenes temprano. Es muy difícil una vez que tienes una gran suite.
Los veo como diferentes por la siguiente razón.
- Las pruebas unitarias pueden realizarse 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 unitarias se mantienen deliberadamente "livianas" para que el desarrollador pueda ejecutarlas con la frecuencia necesaria con un costo mínimo.
Sí. 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 referencias a los tipos de ensamblaje reales .
Simplemente no veo cómo se organizaría la unidad y la integración en un solo proyecto.
si limita la noción de ''prueba unitaria'' al alcance en el nivel de clase, entonces sí, manténgalas separadas
sin embargo, si define la unidad de prueba relevante más pequeña como una característica , algunas de sus pruebas de "unidad" serán técnicamente pruebas de "integración".
Sin embargo, el reajuste de las diversas definiciones / interpretaciones de los términos es en gran medida irrelevante, la partición de los conjuntos de pruebas 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 contra un único ensamblaje y se ejecutan en unos 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, es lógico separar la primera serie de pruebas de la última.
resumen: la distinción de las pruebas de "unidad" e "integración" es irrelevante; paquete de suites de prueba basadas en el alcance operativo