integration-testing - tipos - test programas integrales mx

Pruebas de integración mejores prácticas

Question

Nuestro equipo tiene cientos de pruebas de integración que llegan a una base de datos y verifican resultados. Tengo dos clases básicas para todas las pruebas de integración, una para pruebas de recuperación y otra para crear / actualizar / eliminar pruebas. La clase base solo de recuperación regenera la base de datos durante el TestFixtureSetup por lo que solo se ejecuta una vez por clase de prueba. La clase base CUD regenera la base de datos antes de cada prueba. Cada clase de repositorio tiene su propia clase de prueba correspondiente.

Como puede imaginar, todo esto lleva bastante tiempo (se acerca a 7-8 minutos para correr y crecer rápidamente). Tener esta ejecución como parte de nuestro CI (CruiseControl.Net) no es un problema, pero la ejecución local lleva mucho tiempo y realmente prohíbe ejecutarlos antes de cometer código.

Mi pregunta es: ¿existen prácticas recomendadas para ayudar a acelerar la ejecución de estos tipos de pruebas de integración?

No puedo ejecutarlos en la memoria (a la sqlite) porque usamos algunas funciones específicas de la base de datos (columnas calculadas, etc.) que no son compatibles con sqlite.

Además, todo el equipo debe poder ejecutarlos, por lo que ejecutarlos en una instancia local de SQL Server Express o algo podría estar propenso a errores a menos que las cadenas de conexión sean todas iguales para esas instancias.

¿Cómo está logrando esto en su tienda y qué funciona bien?

¡Gracias!

Answer 1

¿Ha realizado alguna medición (utilizando temporizadores o similar) para determinar dónde pasan las pruebas la mayor parte del tiempo?

Si ya sabe que la recreación de la base de datos es la razón por la que consumen mucho tiempo, un enfoque diferente sería regenerar la base de datos una vez y usar las transacciones para preservar el estado entre las pruebas. Cada prueba de tipo CUD inicia una transacción en la configuración y realiza una reversión en desmontaje. Esto puede reducir significativamente el tiempo empleado en la configuración de la base de datos para cada prueba, ya que una reversión de transacciones es más barata que una recreación completa de la base de datos.

Answer 2

Mantenga sus pruebas rápidas (unidad) y lentas (integración) separadas, para que pueda ejecutarlas por separado. El marco de prueba proporciona cualquier método para agrupar / categorizar las pruebas. Si el marco de prueba no admite agrupar las pruebas, mueva las pruebas de integración a un módulo separado que solo tenga pruebas de integración.

Las pruebas rápidas deben tomar solo unos segundos para ejecutarlas todas y deben tener una alta cobertura de código. Este tipo de pruebas les permite a los desarrolladores refactorizar sin piedad, porque pueden hacer un pequeño cambio y ejecutar todas las pruebas y estar muy seguros de que el cambio no rompió nada.

Las pruebas lentas pueden tardar muchos minutos en ejecutarse y se asegurarán de que los componentes individuales funcionen bien juntos. Cuando los desarrolladores hacen cambios que podrían romper algo que se prueba con las pruebas de integración pero no con las pruebas unitarias, deben ejecutar esas pruebas de integración antes de realizar la confirmación. De lo contrario, las pruebas lentas son ejecutadas por el servidor CI.

Answer 3

Soy un desarrollador de Java, pero he tratado con un problema similar. Descubrí que la ejecución de una instancia de base de datos local funciona bien debido a la velocidad (no hay datos para enviar a través de la red) y porque de esta manera no tiene contención en su base de datos de prueba de integración.

El enfoque general que utilizamos para resolver este problema es configurar los scripts de compilación para leer las cadenas de conexión de la base de datos desde un archivo de configuración, y luego configurar un archivo por entorno. Por ejemplo, un archivo para WORKSTATION, otro para CI. A continuación, configura los scripts de construcción para leer el archivo de configuración en función del entorno especificado. Por lo tanto, las compilaciones que se ejecutan en una estación de trabajo de desarrollador se ejecutan con la configuración de WORKSTATION, y las compilaciones que se ejecutan en el entorno de CI utilizan la configuración de CI.

También ayuda enormemente si se puede crear todo el esquema de la base de datos a partir de un solo script, de modo que cada desarrollador pueda configurar rápidamente una base de datos local para realizar pruebas. Incluso puede extender este concepto al siguiente nivel y agregar la secuencia de comandos de configuración de la base de datos al proceso de compilación, de modo que toda la configuración de la base de datos pueda realizarse mediante secuencias de comandos para mantenerse al día con los cambios en el esquema de la base de datos.

Answer 4

Tenemos una instancia de SQL Server Express con la misma definición de base de datos que se ejecuta para cada máquina de desarrollo como parte del entorno de desarrollo. Con la autenticación de Windows, las cadenas de conexión son estables, sin nombre de usuario / contraseña en la cadena.

Lo que realmente nos gustaría hacer, pero aún no hemos hecho, es ver si podemos lograr que nuestro sistema se ejecute en SQL Server Compact Edition , que es como SQLite con el motor de SQL Server. Entonces podríamos ejecutarlos en memoria, y posiblemente también en paralelo (con múltiples procesos).

Answer 5

en NUnit puede decorar sus clases de prueba (o métodos) con un atributo, por ejemplo:

[Category("Integration")]
public class SomeTestFixture{
    ...
}
[Category("Unit")]
public class SomeOtherTestFixture{
    ...
}

Luego, puede estipular en el proceso de compilación en el servidor que todas las categorías se ejecutan y solo requiere que sus desarrolladores ejecuten un subconjunto de las categorías de prueba disponibles. Las categorías que deben ejecutar dependerían de las cosas que entenderá mejor que yo. Pero lo esencial es que pueden probar a nivel de unidad y que el servidor maneja las pruebas de integración.