¿Cómo organizar las pruebas de integración?

Question

Al escribir las pruebas unitarias, por lo general tienen una clase de prueba por clase de producción, por lo que mi jerarquía se verá algo así:

src/main 
    -package1 
    -classA 
    -classB 
    -package2 
    -classC 
src/test 
    -package1 
    -classATests 
    -classBTests 
    -package2 
    -classCTests 

Sin embargo cuando se hace la integración pone a prueba la organización se vuelve menos rígida. Por ejemplo, puedo tener una clase de prueba que pruebe classA y classB conjuntamente. ¿Dónde lo pondrías? ¿Qué pasa con una clase de prueba que prueba classA, classB y classC juntos?

Además, las pruebas de integración generalmente requieren propiedades externas o archivos de configuración. ¿Dónde los colocas y usas alguna convención de nombres para ellos?

Answer 1

¿Tal vez crear un directorio de pruebas de integración bajo src/test? Claro, para las pruebas de integración la separación se vuelve menos clara, pero hay algo que agrupa a A, B y C juntos, ¿no? Comenzaría con esto y vería cómo van las cosas. Es difícil encontrar una solución perfecta de inmediato y una solución "OK" es mejor que ninguna solución.

Answer 2

Nuestras pruebas de integración tienden a organizarse de la misma manera que nuestras especificaciones. Y tienden a reunirse por categorías y/o características.

Answer 3

Parece que sus pruebas de integración son pruebas unitarias de nivel superior ya que aún las vincula a una o más clases. Intente elegir la clase que depende de todas las demás (transitoriamente) del grupo y asocie la prueba con dicha clase.

Si tiene verdaderas pruebas de integración, la asociación con clases concretas tiene poco valor. Luego, las pruebas se clasifican por áreas temáticas de aplicación (dominios) y por tipos de funcionalidad. Por ejemplo, los dominios son pedidos, envíos, facturas, autorizaciones, etc. y los tipos de funcionalidad son transaccionales, web, de mensajería, de lotes, etc. Sus permutaciones le darían un buen primer corte sobre cómo organizar las pruebas de integración.

Answer 4

He descubierto que al hacer TDD no siempre ocurre que en las pruebas unitarias haya una relación 1: 1 entre las clases y las pruebas. Si lo hace, tendrá dificultades para refactorizar. De hecho, después de algunas refactorizaciones, suelo terminar con aproximadamente 50% de acoplamientos 1: 1 y 50% de pruebas que podría vincular a varias clases o grupos de pruebas que se vinculan a una sola clase.

Pruebas de integración ocurren si intenta probar que algo está funcionando o no. Esto sucede cuando estás preocupado porque necesitas entregar algo, o si encuentras un error. Intentar obtener una cobertura completa de las pruebas de integración es una mala idea (por decirlo suavemente).

Lo más importante es que una prueba necesita contar una historia. En términos BDD'ish: dado que tienes tal, al hacer esto, eso debería suceder. Las pruebas deben ser ejemplos de cómo pretende que las personas usen la unidad, API, aplicación, servicio, ...

La granularidad y organización de sus pruebas se basará en su historia. No debe diseñarse con reglas simplistas por adelantado.

Answer 5

Estoy de acuerdo con la respuesta de f4. Este tipo de pruebas (nivel más alto que UT) generalmente no tiene ninguna correlación con clases particulares. Sus pruebas deben cumplir con los requisitos y especificaciones del proyecto.

En caso de que realmente necesite desarrollar un proyecto de prueba adaptado a sus requisitos de prueba, recomendaría el siguiente enfoque: un proyecto separado con paquetes por requerimiento o historia del usuario (dependiendo de su enfoque para gestionar los requisitos). Por ejemplo:

 
src/itest 
    -package1 - corresponds to story#1 
    -classA - test case1 
    -classB - test case2 
    -package2 - corresponds to story#1 
    -classC - test case2 
    -packageData - your common test data and utilities 

Sin embargo, tenga en cuenta - de hacer una integración o pruebas de nivel de sistema suele ser tarea complicada y su alcance podría fácilmente ser más amplias que las pruebas de proyectos de software puede cubrir. Debe estar preparado para considerar herramientas de automatización de pruebas de terceros, porque a nivel de integración o prueba de sistema a menudo es un enfoque más eficiente que desarrollar un paquete de pruebas personalizado.