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

Question

A diferencia de mi pregunta anterior , voy a tratar de dar a mis necesidades.

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 #.
• Prueba debe conducir un navegador web e interactuar con IVU al igual que lo haría un usuario.
• Prueba debe ser capaz de configurar un escenario de prueba en la base de datos.
• Prueba debe ser capaz de afirmar que las interacciones del usuario tuvo el efecto esperado en la base de datos.
• Una vez finalizada la prueba, debería ser capaz de revertir todos los cambios que hizo en DB.

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 ningún ejemplo concreto de cómo implementar esto. No habría ningún problema si yo estaría haciendo pruebas unitarias. En ese caso TransactionScope sería más que suficiente.

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

Sin embargo esa pregunta solo es casi idénticos. Mi solicitud es parte de una familia de servicios, todos ellos el acceso al mismo conjunto de tablas de bases de datos. Cantidad de datos de prueba requerida no permitir el uso eficiente de la gota / crear scripts, así que hay alguna solución alternativa para esto?

Estamos utilizando SQL Server 2005, y no soy muy hábil en la magia de base de datos, por lo que si hay alguna manera de utilizar SQL scripting aparte de gota / creamos, entonces eso podría ser una opción.

Editar 2:

En base a las respuestas y un poco de cabeza adicional arañazos, vamos a ir a las bases de datos más ligeros para los desarrolladores para llevar a cabo las pruebas de unidad-, de integración y funcional. Esto nos permite utilizar secuencias de comandos SQL para configurar y derribar la prueba.

Answer 1

Los cambios realizados en una transacción son accesibles solamente dentro de dicha transacción. También envolver la prueba en un ámbito de transacción (si es posible) haría que la prueba se comportan de manera diferente que la cosa real en un aspecto muy crítico (transacciones).

Es mucho mejor usar una imagen de base de datos que se restaura antes de cada serie de pruebas. De esta manera después de la suite completa y la verificación se realiza, se le cae la base de datos de prueba. La próxima carrera, durante la configuración de conjunto, 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 un script que despliega la base de datos a partir de cero y ejecutar esa secuencia de comandos durante la instalación de baño.

Por cierto, no es factible para restaurar a su estado original antes de cada prueba. Más genéricamente, no es factible tener largos pasos de configuración de prueba y limpieza individuales. A medida que agrega más pruebas el tiempo dedicado a la restauración de la base de datos a condición de prueba listo entre las pruebas a ser lo mismo inmanejable. Suites con cientos de pruebas son pruebas de funcionamiento bastante comunes y lleno de decenas de miles de pruebas que significaría horas y horas simplemente la restauración de la base de datos de prueba. El diseño de su prueba individual de manera que se puedan ejecutar de forma independiente, es decir. 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 que quieren pruebas posteriores para poder ejecutar y producir válida resultados. A veces, estos requisitos se contradicen entre sí, pero hay que tomarlos en consideración y el diseño de la prueba que les rodea.

Answer 2

Si la cantidad de datos necesarios para restaurar la base de datos a un conocido buen estado es prohibitivo de la gota / crear secuencias de comandos y que se están ejecutando las pruebas de desarrollador o edición Enterprise de SQL 2005, usted podría mirar en crear una instantánea de base del buen estado, y volver a ella antes de cada prueba. Esto es considerablemente más rápido que una restauración completa, aunque todavía puede ser demasiado tiempo si usted tiene cientos de pruebas.

Answer 3

No se pierda Amnesia , que he recomendado en esta pregunta relacionada .