Integration vs Unit Testing

Question

Estoy desarrollando con Grails. Dado que el marco de trabajo arrancará datos y un contexto de primavera completamente enrojecido, me parece que escribo muchas pruebas de integración para servicios. Permítanme reformular eso: me parece que no escribo pruebas de unidad para servicios, solo pruebas de integración. ¿Es una mala idea? El único inconveniente que veo es que mis pruebas tardan un poco más en ejecutarse.

Uso pruebas unitarias en controladores, como en un controlador estoy probando los diversos flujos de aplicaciones, tipos de resultados, lógica de redirección, etc. Pero la mayoría de las pruebas que escribo son pruebas de integración. Esto parece un descanso de las pruebas J2EE tradicionales, donde se escriben principalmente pruebas unitarias.

edit- para ser claros, no estoy escribiendo pruebas de integración porque el código es tan complicado que solo lo harán las pruebas de integración. Estoy escribiendo pruebas de integración porque es más fácil probar todo junto, ya que el framework te da mucho. Me burlo de ciertas cosas, como si un servicio colabora con el acegi authenticationService, me burlo de eso. También me burlo cada vez que interactuamos con un servicio web, porque es necesario para obtener una prueba que se ejecuta sin una configuración especial.

Answer 1

Veo claramente una tendencia hacia pruebas más funcionales y menos pruebas unitarias, en particular para componentes muy conectados con poca lógica. Si implemento un algoritmo complicado en una clase particular, por lo general escribiré pruebas unitarias para ello, pero si la complejidad se debe a la integración con otros componentes (que es muy frecuentemente el caso), las pruebas unitarias no valen la pena.

Answer 2

Es posible que pueda utilizar un marco simulado para aislar diferentes partes de sus servicios para pruebas individuales. En lugar de confiar en el contexto masivo de Spring, crea una instancia directa de tu clase de servicio y rellena las dependencias que no son directamente relevantes para la prueba con simulacros. Es posible que necesite un poco de refactorización para desacoplar sus dependencias, pero generalmente será lo mejor. Esto puede llevar a escribir más y pruebas más pequeñas en lugar de basarse en unas pocas pruebas de integración grandes.

Estoy en una situación similar donde muchas pruebas establecidas son realmente pruebas de integración, y puede ser difícil, pero no imposible, cambiar esto en el futuro.

Answer 3

En general, la medida importante es la cobertura del código.

En puede ser ventajoso realizar pruebas de integración si la interfaz global es más estable (menos sujeta a cambios).

Answer 4

Debe probar lo antes posible, porque desea que los errores aparezcan lo más pronto posible, idealmente mientras nuestro código aún esté bajo su propio control. Cuanto más tarde se descubra un error, mayores serán los costos de la corrección.

Si está exponiendo lógica no trivial, debe probar la lógica de las principales rutas de decisión con pruebas unitarias y la exposición de esa lógica y la interacción con dependencias externas en las pruebas de integración.

Si usted es un desarrollador solitario o trabaja en un equipo pequeño, a veces es difícil ver la distinción entre la unidad y las pruebas de integración. Si se encuentra en un entorno en el que varios equipos trabajan en un solo producto, la suposición es que la lógica de su código ya se ha verificado (prueba de unidad) y ahora desea ver cómo funcionan los módulos (prueba de integración) .

No es un buen patrón para cargar demasiado en la prueba de integración, porque está posponiendo la prueba a una fase posterior en su proyecto o entorno de desarrollo, y tarde o temprano descubrirá que está descubriendo errores una vez el código ha salido de tu escritorio. Eso significará demorar todo el lanzamiento del producto y posiblemente el mismo mientras arregla algo que podría y debería haber descubierto antes.