Pruebas de integración y unidad en el gran proyecto Grails

Question

Generalmente es más complicado escribir pruebas unitarias debido a tener que lidiar con objetos simulados que pruebas de integración en un gran proyecto de Grails. Este article incluso sugiere que podemos eliminar las pruebas unitarias y escribir solo pruebas de integración que estoy de acuerdo.

La única desventaja que veo es la velocidad de ejecución para la prueba de integración en comparación con la misma prueba unitaria.

¿Qué piensa sobre esto de su experiencia real trabajando en un proyecto de Grails a gran escala?

Si escribimos una prueba unitaria que prueba exactamente el mismo método y también una prueba de integración de escritura que también prueba exactamente el mismo método, ¿es esta la forma normal de escribir pruebas?

¿A qué terminaste en términos de proporción de pruebas unitarias a pruebas de integraciones en un gran proyecto real de Grails?

¿Ha completado con éxito un gran proyecto de Grails sin escribir ninguna prueba?

Answer 1

Siempre escribo mis pruebas como pruebas unitarias si es posible. Hago esto porque:

• pruebas unitarias se ejecutan más rápido
• prefiero probar cada componente de forma aislada, en lugar de probar todos los componentes integrados juntos, porque esto hace que sea más fácil identificar la fuente de un error
• el entorno de pruebas de unidad es más simple (por ejemplo, no contexto de aplicación de primavera), así que hay un menor número de fuentes potenciales de fracaso que no están relacionados con la prueba que se realiza

un ejemplo de donde me gustaría escribir una prueba de integración se si quiero probar un Sprin g bean que he definido en resources.groovy. Aunque podría instanciar la clase y probarla directamente, mi prueba necesitaría conocer la clase de implementación actual de ese bean (que podría cambiar).

En el largo plazo, creo que en realidad es más complicado escribir pruebas de integración, porque el costo de mantenerlas en el tiempo es mayor que las pruebas unitarias. Groovy/Grails tiene un excelente soporte para burlarse/trocear, por lo que el costo de burlarse de las dependencias en pruebas unitarias es relativamente bajo. Aquí está un ejemplo del mundo real a partir de una de mis pruebas de unidad en la que:

• maqueta del grano messageSource primavera que normalmente sólo estará disponible en una prueba de integración
• simulacros de dos clases de comando de modo que puedo llamar a la validate() método, inspeccionar la propiedad .errors, etc.

---

class MyUnitTests extends GrailsUnitTestCase { 

    MessageSource messageSource 

    protected void setUp() { 

     super.setUp() 
     // mockForConstraintsTests is a method provided by GrailsUnitTestCase 
     [Complex, CategoryCommand].each {mockForConstraintsTests(it)} 

     // 'mockMessage' will be returned by every method call on messageSource 
     messageSource = {Object[] args -> "mockMessage"} as MessageSource 
    } 
} 

Answer 2

he trabajado en 3 grandes aplicaciones Grails, y innumera los más pequeños. Mi proyecto actual tiene una combinación de pruebas unitarias y de integración (actualmente 2110 pruebas unitarias y 493 pruebas de integración).

He pasado mucho tiempo tratando de mejorar la velocidad de las pruebas y haciendo que las pruebas sean más fáciles de mantener.

Mis pruebas de integración son a menudo un híbrido en el que si yo estoy probando un servicio, podría burlarse de algunos otros servicios/métodos que se están llamados a garantizar consigo los valores que desee, pero dejan en otras piezas de integración para ejercer HQL o integración de base de datos. Para este fin, utilizo prototype instances of what are normally singleton services para que pueda limpiar con la instancia de servicio sin contaminar las pruebas posteriores.

Creo que el plugin build-test-data es invaluable para crear pruebas de unidades que se puedan mantener, ya que me permite crear datos de prueba donde doblo explícitamente las piezas que necesito y dejo que el complemento complete los demás detalles requeridos. Crear datos de prueba en pruebas de integración es más fácil para mí que burlarlo en pruebas unitarias.

Si utiliza pruebas de integración y unidad, eventualmente la velocidad de ejecución de todas las pruebas en serie se convertirá en un impedimento. Mi equipo usa el script splitTests.groovy para derivar dos hilos separados, uno para pruebas unitarias, uno para pruebas de integración. Esto hace que nuestras pruebas sean un 40% más rápidas. Es posible una paralelización adicional, pero aún no hemos llegado allí (y los guiones de Gant actuales de grial son bastante desagradables bajo las sábanas, estoy esperando la reescritura de Gradle en Grails 2.0).

Las pruebas unitarias son agradables para golpear todos los recovecos condicionales de un método (aunque si tienes demasiados, tu complejidad ciclomática es probablemente demasiado alta y deberías refactorizar). Las pruebas de integración son útiles para ejercitar la integración de bases de datos y servicios, así como para ayudarlo a comprender lo que ha roto al cambiar una parte del código.

Creo que el valor de refactorización que obtiene de tener una alta cobertura de prueba depende en parte de que algunas de las pruebas sean pruebas de integración. Si todo lo que tiene son pruebas unitarias que no interactúan con otras piezas de código, no se le avisará de las áreas afectadas cuando se realiza un cambio de código, y dado que groovy es un lenguaje dinámico, es probable que el compilador no lo ayude a encontrar estas áreas tampoco.

Answer 3

En este artículo se llega a sugerir que incluso puede acabar con las pruebas unitarias por completo y escribir sólo las pruebas de integración que tiendo a

Ese artículo fue escrito con Grails 1.0

marca esta complementary article misma columna , mismo autor