¿Debo separar las pruebas unitarias y las pruebas de integración?

17

Tengo que escribir pruebas unitarias y pruebas de integración para un proyecto.

  • ¿Deben colocarse todas las pruebas en una sola carpeta de pruebas ?
  • ¿O deberían las pruebas unitarias y las pruebas de integración estar cada una en una carpeta de pruebas separada ?
  • ¿O debería incluso ponerlos en proyectos separados ?

Si los mantengo juntos, ¿hay alguna ventaja o inconveniente con este enfoque?

architecture unit-testing integration-tests Ahmed Ragheb
fuente
1
Si está operando en un entorno de CI, lo importante es que se pueden identificar fácilmente (por atributo, etc.) ya que las pruebas de integración no siempre se ejecutan en el servidor de compilación.
Robbie Dee
3
Relacionado: Pruebas: unidad vs. integración vs. otros, ¿cuál es la necesidad de separación?
mouviciel

Respuestas:

18

En general: sí, debe colocar pruebas de integración y pruebas unitarias en diferentes carpetas. A menudo, los programadores no trazan una línea clara entre estos dos tipos de pruebas y simplemente escriben cualquier tipo de prueba que sea útil. Pero las pruebas de integración tienden a ser más lentas porque a menudo implican:

  • Consultas de bases de datos
  • Solicitudes de red
  • Comportamiento dependiente del tiempo
  • Grandes cantidades de datos

En contraste, una prueba unitaria se burlaría de cualquier operación costosa, por lo que las pruebas unitarias tienden a ejecutarse rápidamente (de hecho, la parte más lenta de ejecutar la prueba es a menudo el marco de prueba en sí).

Cuando un programador está trabajando en el sistema, está en un ciclo de edición-prueba. Cuanto más rápido reciban comentarios de prueba y cuanto más corto sea el ciclo, más productivos pueden ser. Entonces, allí solo queremos ejecutar pruebas importantes que se completen rápidamente. El conjunto de pruebas completo solo se ejecutará como parte de un proceso de control de calidad, por ejemplo, en un servidor CI.

Esto significa que los conjuntos de pruebas grandes deben clasificarse. ¿Solo podemos seleccionar pruebas unitarias para un componente en particular? ¿Podemos excluir las pruebas lentas? Una manera simple de hacer esto es mantener diferentes conjuntos de pruebas en diferentes directorios. Si solo tiene muy pocas pruebas, un solo directorio también estaría bien siempre que un programador pueda seleccionar fácilmente un subconjunto de pruebas.

Lo que sea que permita a un programador obtener retroalimentación rápidamente es bueno. El conjunto de pruebas más completo no importa si no se ejecuta regularmente.

Otras lecturas:

amon
fuente
Al separar las carpetas, ¿mantiene cada una de ellas en el mismo paquete que el código de producción (para que pueda probar los métodos protegidos)? Ejemplo, crea un módulo maven para pruebas unitarias y otro módulo maven para las pruebas de integración. De esa manera, puede separarlos y aún probar fácilmente los métodos protegidos.
ihebiheb
@ihebiheb En Java, usar la visibilidad del paquete está bastante mal visto. En algunos casos, puede ser útil usarlo y acceder a estas API desde pruebas unitarias. Pero en general, eso es innecesario. Las pruebas de estilo de integración nunca necesitan acceso a miembros privados de paquetes. El que las pruebas se realicen o no en un proyecto Maven separado depende de cómo desee ejecutarlas y desplegarlas. No estoy tan interesado en Java / Maven para poder decirte lo que es sensato aquí.
amon