Pruebas de integración de base de datos

Question

Cuando realiza pruebas de integración con solo su capa de acceso a datos o la mayoría de la pila de aplicaciones. ¿Cuál es la mejor manera de evitar que las pruebas múltiples entren en conflicto si se ejecutan en la misma base de datos?

Answer 1

Transacciones.

Lo que el rubí en los carriles marco de prueba de unidad hace es la siguiente:

Load all fixture data. 

For each test: 

    BEGIN TRANSACTION 

    # Yield control to user code 

    ROLLBACK TRANSACTION 

End for each 

Esto significa que

1. cualquier cambio hace que su prueba a la base de datos no afectará a otros hilos, mientras que es in- progreso
2. Los datos de la siguiente prueba no están contaminados por las pruebas anteriores
3. Esto es aproximadamente un billón de veces más rápido que la recarga manual de datos para cada prueba.

Por mi parte, creo que esto está muy bien

Answer 2

Para aplicaciones de bases de datos simples, me resulta valioso utilizar SQLite. Le permite tener una base de datos única e independiente para cada prueba.

Sin embargo, solo funciona si utiliza una funcionalidad SQL genérica simple o puede ocultar fácilmente las pequeñas diferencias entre SQLite y su sistema de base de datos de producción detrás de una clase, pero siempre he encontrado que es bastante fácil en SQL aplicaciones que he desarrollado.

Answer 3

quería aceptar respuestas tanto Orion Edwards gratuito de ñus y pero no me dejaron. La razón por la que quería hacer esto es que había llegado a la conclusión de que estas eran las dos formas principales de hacerlo, pero que elegir debía depender del caso individual (principalmente el tamaño de la base de datos).

Answer 4

También ejecute las pruebas en diferentes momentos, para que no afecten el rendimiento o la validez de los demás.

Answer 5

Solo para agregar a la respuesta de Wildebeest también usé HSQLDB para hacer una prueba de tipo similar donde cada prueba obtiene una instancia limpia de la base de datos.

Answer 6

Si bien no es tan inteligente como el marco de prueba de la unidad Rails en una de las otras respuestas aquí, la creación de datos distintos por prueba o grupo de pruebas es otra forma de hacerlo. El nivel de fastidio con esta solución depende de la cantidad de casos de prueba que tenga y cuán dependientes estén uno del otro. La tediosidad será cierta si tiene una base de datos por prueba o un grupo de pruebas dependientes.

Al ejecutar el banco de pruebas, usted carga los datos al inicio, ejecuta el conjunto de pruebas, descarga/compara los resultados asegurándose de que el resultado real cumpla con el resultado esperado. Si no, haz el ciclo nuevamente. Cargar, ejecutar suite, descargar/comparar.