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

Question

Me gustaría saber algo, sé que para hacer que su prueba sea más fácil, debe usar el simulacro durante la prueba unitaria para probar solo el componente que desee, sin dependencias externas. Pero en algún momento, tiene que morder el problema y probar las clases que interactúan con su base de datos, archivos, red, etc.

Mi pregunta principal es: ¿qué hace para probar estas clases?

• No creo que la instalación de una base de datos en mi servidor CI sea una buena práctica, pero ¿tiene otras opciones?

• ¿Debo crear otro servidor con otras herramientas de CI, con todas las dependencias externas?

• ¿Debo ejecutar la prueba de integración en mi CI tan a menudo como las pruebas de mi unidad?

• ¿Quizás una persona a tiempo completo debería encargarse de probar estos componentes manualmente? (O el encargado de crear el entorno de prueba y configuración de la interacción entre su clase y su dependencia externa, como la edición de archivos de configuración de la aplicación)

me gustaría saber ¿cómo se hace en el mundo real .

Answer 1

Me gustaría saber cómo se hace en el mundo real ?

En el mundo real no hay una receta simple sobre qué hacer, pero hay una verdad que lo guía: desea detectar errores/errores/fallas de prueba tan pronto como sea posible después de que se introducen. Deja que sea tu guía; todo lo demás es técnica.

Un par de técnicas comunes:

• pruebas de circulación en paralelo. Esta es mi preferencia; Me gusta tener dos sistemas, cada uno ejecutando su propia instancia de CruiseControl * (que soy un committer), uno que ejecuta las pruebas de la unidad con comentarios rápidos (< 5 minutos) mientras que otro sistema ejecuta las pruebas de integración constantemente. Me gusta esto porque minimiza la demora entre cuando ocurre un checkin y una prueba del sistema puede atraparlo. La desventaja que a algunas personas no les gusta es que puede terminar con múltiples fallas de prueba para el mismo registro, tanto una falla de prueba de unidad como una falla de prueba de integración. No creo que esto sea un inconveniente importante en la práctica.

• Un modelo de ciclo de vida en el que las pruebas de sistema/integración se ejecutan solo después de que han pasado las pruebas unitarias. Hay herramientas como AnthillPro * que se basan en este tipo de modelo y el enfoque es muy popular. En su modelo, toman los artefactos que han superado las pruebas unitarias, los implementan en un servidor de etapas separado y luego ejecutan las pruebas de sistema/integración allí.

Si usted tiene más preguntas sobre este tema os recomiendo el Continuous Integration and Testing Conference (CITCON) y/o la CITCON mailing list.

• Hay muchos CI and build|process automation tools por ahí. Estos son solo representantes de su clase de herramientas.

Answer 2

Dependiendo de la naturaleza real de las pruebas de integración, recomendaría utilizar un motor de base de datos incrustado que se recrea al menos una vez antes de cualquier ejecución. Esto permite que las pruebas de diferentes compromisos funcionen en paralelo y proporciona un punto de partida bien definido para las pruebas.

Los servicios de red, por definición, también se pueden instalar en otro lugar.

Siempre tenga mucho cuidado, para mantener su máquina CI separada de cualquier entorno dev o prod.

Answer 3

El enfoque que he visto tomar más a menudo es ejecutar pruebas unitarias inmediatamente en el registro y ejecutar pruebas de integración más largas a intervalos fijos (posiblemente en un servidor diferente, eso es realmente según tus preferencias). También he visto las pruebas de integración divididas en pruebas de integración de "ejecución corta" y pruebas de integración de "larga ejecución", que se ejecutan en diferentes intervalos (las pruebas de "ejecución breve" se ejecutan cada hora, por ejemplo, y el "período largo"). "correr" las pruebas se ejecutan durante la noche).

El verdadero objetivo de cualquier prueba automatizada es obtener retroalimentación a los desarrolladores tan rápido como sea posible. Con eso en mente, debe ejecutar pruebas de integración tan a menudo como sea posible. Si hay una gran variación en la duración de la ejecución de sus pruebas de integración, debe ejecutar las pruebas de integración más rápidas con más frecuencia y las pruebas de integración más lenta con menos frecuencia. La frecuencia con la que ejecute cualquier conjunto de pruebas dependerá de cuánto tarden todas las pruebas en ejecutarse, y de qué tan perjudicial sea la ejecución de la prueba para las pruebas de menor duración (incluidas las pruebas unitarias).

Me doy cuenta de que esto no responde a toda su pregunta, pero espero que le dé algunas ideas sobre la parte de la programación.

Answer 4

No sé en qué tipo de plataforma estás, pero uso Java. Donde trabajo, creamos pruebas de integración en JUnit e inyectamos las dependencias apropiadas usando un contenedor DI como Spring. Se ejecutan contra una fuente de datos real, tanto por los propios desarrolladores (normalmente un pequeño subconjunto) como por el servidor de CI.

La frecuencia con la que ejecuta las pruebas de integración depende de cuánto tarden en ejecutarse, en mi opinión. Ejecútelos tan a menudo como pueda.Deje a la persona real fuera de esto y permita que ejecute pruebas manuales del sistema en áreas que son difíciles o demasiado costosas para la automatización de las pruebas (por ejemplo: ortografía, posición de diferentes componentes de la GUI). Deje la edición de los archivos de configuración en una máquina. Donde trabajo, tenemos las variables del sistema (DEV; TEST, etc.) configuradas en las computadoras, y deja que la aplicación elija un archivo de configuración basado en eso.