Pruebas de integración de bases de datos.

Question

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

Answer 1

Actas.

Lo que hace el marco de prueba unitario de Ruby on Rails es esto:

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 que realice su prueba en la base de datos no afectará a otros subprocesos mientras esté en progreso.
2. Los datos de la siguiente prueba no están contaminados por pruebas anteriores.
3. Esto es aproximadamente un millón de veces más rápido que recargar manualmente los datos para cada prueba.

Por mi parte, creo que esto es genial.

Answer 2

Para aplicaciones de bases de datos simples encuentro usando SQLite inestimable.Le permite tener una base de datos única e independiente para cada prueba.

Sin embargo, solo funciona si está utilizando 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 las aplicaciones SQL que he desarrollado.

Answer 3

Solo para agregar a la respuesta de Free Wildebeest, también he usado HSQLDB para realizar una prueba de tipo similar donde cada prueba obtiene una instancia limpia de la base de datos.

Answer 4

Quería aceptar las respuestas de Free Wildebeest y Orion Edwards, pero no me dejó.La razón por la que quería hacer esto es que llegué a la conclusión de que estas eran las dos formas principales de hacerlo, pero cuál elegir depende del caso individual (principalmente el tamaño de la base de datos).

Answer 5

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

Answer 6

Si bien no es tan inteligente como el marco de pruebas unitarias de Rails en una de las otras respuestas aquí, crear datos distintos por prueba o grupo de pruebas es otra forma de hacerlo.El nivel de tedio con esta solución depende de la cantidad de casos de prueba que tenga y de cuán dependientes sean unos de otros.El tedio será cierto si tiene una base de datos por prueba o grupo de pruebas dependientes.

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