compilaciones nocturnas frente a integración continua: pruebas automáticas de larga ejecución

Question

Tenemos el "problema" de un gran conjunto automatizado de pruebas de integración. Si bien nuestros tiempos de construcción son razonables (< 1 hora), las pruebas generalmente demoran> 6 horas en completarse.

Si bien es genial tener esta gran parte de la funcionalidad probada en nuestras ejecuciones de compilación, obviamente es una barrera para la implementación de CI, que me ha resultado muy útil para mantener los árboles fuente en un estado "siempre edificable" .

He revisado el debate como this one, que se detallan las distinciones.

Esto me lleva a algunas preguntas:

1. ¿El dictado CI o recomiendan Unidad frente a la automatización de pruebas de integración? He escuchado unidades solo en el pasado, pero no encuentro ninguna declaración (o razón) para esto en una búsqueda rápida.

2. ¿Cuál es una buena "mejor práctica" para que los tiempos combinados y los tiempos de prueba automatizados tengan un IC eficaz para un equipo? Mi instinto me dice que esto debería ser < 2 horas como el peor de los casos, y probablemente < 1 hora para ser realmente efectivo. En teoría, podríamos dividir las pruebas para que se ejecuten en paralelo y probablemente las ejecutemos en menos de 2 horas, pero esto aún sería una ejecución de 3 horas.

3. ¿Cuál es la mejor forma de avanzar de Nightly Builds + Integration Tests de larga duración a CI? Estoy pensando en construir CI con algunas pruebas unitarias esqueléticas solamente, en combinación con versiones nocturnas que continúan con las pruebas de integración.

Cualquier recomendación de herramientas también son bienvenidos (sólo para Windows C#/C++ código base)

Answer 1

Para la mayoría de los proyectos, sin embargo, la directriz XP de una acumulación diez por minuto es perfectamente dentro de lo razonable. La mayoría de nuestros proyectos modernos logran esto. Es vale la pena poner en esfuerzo concentrado para que esto suceda, porque cada minutos que reduce el tiempo de compilación es un minuto guardado para cada desarrollador cada vez que se comprometen. Como CI exige confirmaciones frecuentes, esto suma durante mucho tiempo.

Fuente: http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast

¿Por qué se tarda 6 horas? ¿Cuántas pruebas tienes? ¿Cuál es la razón de la unidad de prueba en comparación con los integrados? Es probable que tenga muchas más pruebas integradas o que su unidad de prueba no sea realmente una unidad. ¿Están sus pruebas de unidad tocando el DB? Este podría ser el problema.

6 horas es un largo largo tiempo. El artículo anterior tiene algunos consejos.

Answer 2

Hay algunas cosas aquí.

En general, tendrá una serie de compilaciones, una que compila & pruebas de unidad de funcionamiento, una que hace eso y ejecuta pruebas de aceptación locales, y una que ejecuta pruebas de integración.

Definitivamente no necesita necesita una compilación única que hace de todo.

Sus tiempos de construcción para mí suenan bastante largos - recuerde que el punto aquí es dar rápida comentarios de que algo salió mal. No sé mucho sobre tu proyecto, pero creo que deberías intentar que tu compilación y prueba de la unidad se reduzcan a menos de dos o tres minutos. Esto es perfectamente alcanzable, en todos los proyectos, pero muy grandes, por lo que si las pruebas de su unidad toman tiempo, entonces es hora de empezar a preguntar por qué.

6 horas es también un tiempo muy largo. ¿Estás seguro de que tus pruebas están probando lo correcto? ¿tienes demasiadas pruebas de amplio alcance? ¿Estás usando "sleep()" para maquillar por el hecho de que no has modelado bien la asincronía en tu código de prueba?

Probablemente deberías conseguir el libro "Entrega continua" de Jez Humbles, y echar un vistazo al Software orientado a objetos de crecimiento para saber cómo escribir pruebas de unidad/integración. GOOS usa Java como lenguaje de implementación, pero todos los conceptos son los mismos.