Cómo automatizar pruebas funcionales/de integración y reversiones de bases de datos

Question

A diferencia de mi previous question, intentaré cumplir mis requisitos.

Estoy tratando de encontrar algún tipo de marco/metodología/"cosa" que se ajustara a lo siguiente:

• Capacidad para escribir una prueba automatizada, preferiblemente por escrito en Visual Studio, usando C#.
• La prueba debe conducir un navegador web e interactuar con SUT tal como lo haría un usuario.
• La prueba debería ser capaz de configurar un escenario de prueba en DB.
• La prueba debería ser capaz de afirmar que las interacciones del usuario tuvieron el efecto esperado en DB.
• Una vez completada la prueba, debería poder deshacer todos los cambios realizados en la base de datos.

Mi primer intento fue utilizar la prueba NUnit para conducir selenio (y Watin antes de eso), pero se enfrentó a un poco de un problema (ver el enlace anterior), mientras que el uso de TransactionScope a revertir los cambios navegador selenio impulsada hizo en el DB.

¿Alguien ha hecho algo como esto en el "mundo real"? He encontrado algunas referencias a través de Google, pero no he podido encontrar ejemplos concretos sobre cómo implementar esto. No habría ningún problema si estuviera haciendo pruebas unitarias. En ese caso, TransactionScope sería suficiente.

Editar: R. Harvey me señaló this pregunta, que es casi idéntica a mi situación.

Sin embargo, esa pregunta es solo casi idéntica. Mi aplicación es parte de una familia de servicios, todos ellos acceden al mismo conjunto de tablas de base de datos. La cantidad de datos de prueba requeridos no permite un uso eficiente de los scripts drop/create, ¿hay alguna solución alternativa para esto?

Estamos utilizando SQL Server 2005, y no soy muy hábil en la magia de la base de datos, por lo que si hay alguna forma de utilizar secuencias de comandos sql que no sean drop/create, entonces podría ser una opción.

Edición 2:

Sobre la base de las respuestas y arañar un poco de cabeza adicional, vamos a ir a las bases de datos más ligeros para los desarrolladores para realizar unidad-, las pruebas de integración y funcional. Esto nos permite usar scripts sql para configurar y demoler la prueba.

Answer 1

Los cambios realizados en una transacción solo son visibles dentro de dicha transacción. Además, envolver la prueba en un ámbito de transacción (si es posible) haría que la prueba se comportara de manera diferente a la real en un aspecto muy crítico (transacciones).

Es mucho mejor utilizar una imagen de base de datos que restaura antes de cada conjunto de pruebas. De esta forma, una vez que el conjunto se completa y se realiza la verificación, se descarta la base de datos de prueba. La siguiente ejecución, durante la configuración de la suite, la base de datos se vuelve a crear a partir de la imagen guardada en un estado prístino listo para la prueba. Aún mejor sería tener una secuencia de comandos que implemente la base de datos desde cero y ejecutar esa secuencia de comandos durante la configuración de la suite.

Btw no es factible restaurar a un estado prístino antes de cada prueba. De manera más genérica, no es factible tener una configuración de prueba individual larga y pasos de limpieza.A medida que agregue más pruebas, el tiempo invertido en restaurar la base de datos a la condición de prueba entre pruebas se volverá inmanejable. Las suites con cientos de pruebas son bastante comunes y las pruebas completas de decenas de miles de pruebas significarían horas y horas dedicadas a la restauración de la base de datos para la prueba. Diseña tu prueba individual para que se puedan ejecutar de forma independiente, es decir. la prueba N tiene que producir resultados válidos incluso si la prueba N-1 falló.

Otra cosa a considerar es la investigación de falla, usted quiere que su prueba fallida para salir de la base de datos en un estado que puede ser investigado para obtener información significativa y desea pruebas posteriores para poder ejecutar y producir resultados válidos. A veces, estos requisitos se contradirán entre sí, pero debe tenerlos en cuenta y diseñar su prueba a su alrededor.

Answer 2

Si la cantidad de datos requeridos para restaurar la base de datos a un estado conocido es prohibitiva de soltar/crear scripts y está ejecutando pruebas en la edición Developer o Enterprise de SQL 2005, puede consultar creating a database snapshot del bien estado, y reverting to it antes de cada prueba. Esto es considerablemente más rápido que una restauración completa, aunque puede llevar mucho tiempo si tiene cientos de pruebas.

Answer 3

No te pierdas Amnesia que recomendé en this related question.