¿Cómo prueba (unidad) el esquema de la base de datos?

Question

Cuando hay un número de personas trabajando en un proyecto, todos los que podrían alterar el esquema de la base de datos, ¿cuál es la forma más sencilla de probar/probar/verificar la unidad? La sugerencia principal que hemos tenido hasta ahora es escribir pruebas para cada tabla para verificar nombres de columnas, restricciones, etc.

¿Alguien más ha hecho algo similar o más simple? Estamos usando C# con SQL Server, si eso hace una diferencia real.

actualizaciones:

• El segmento del proyecto que estamos trabajando es el uso de paquetes SSIS para hacer la mayor parte del trabajo lo que hay muy poco de código C# para escribir pruebas unitarias agains.
• El código para crear tablas/procedimientos almacenados se extiende a través de archivos SQL. Debido al sistema de compilación, también podríamos mantener un archivo de proyecto de VS DB por separado, pero no estoy seguro de cómo eso nos ayudaría a verificar el esquema tampoco.

Answer 1

Una posible respuesta es utilizar Visual Studio para desarrolladores de bases de datos y mantener su esquema en control de código fuente con el resto de su código. Esto le permite ver las diferencias y obtiene un historial de quién cambió qué.

Alternativamente, podría utilizar una herramienta como SQLCompare para ver qué se ha modificado en una base de datos en comparación con otra.

Answer 2

¡Esa es una pregunta interesante! Existen muchas herramientas para probar los procedimientos almacenados pero no para probar el esquema de la base de datos.

¿No encuentra que las pruebas unitarias escritas para el código generalmente encuentran algún problema con el esquema de la base de datos?

Un enfoque que he usado es escribir procedimientos almacenados para copiar datos de prueba del esquema del desarrollador a un esquema de prueba. Esto es bastante difícil y está listo ya que los procedimientos almacenados generalmente se bloquean cuando se encuentran diferencias entre los esquemas, pero lo alertan de cualquier cambio que no haya sido informado.

¿Y nominar a alguien para ser el DBA que supervisa los cambios en el esquema?

Answer 3

Su base de datos (relacional) hace dos cosas por lo que a mí respecta: 1) Retener datos y 2) Mantener las relaciones entre los datos.

de datos que contiene no es un comportamiento por lo que no probarlo

Y para asegurar las relaciones simplemente utilizar restricciones. Muchas restricciones Por todo el lugar.

Answer 4

Esto realmente no se ajusta al paradigma de prueba unitaria. Sugeriría una versión que controle el esquema y que limite el acceso de escritura a un solo miembro calificado del equipo, como el DBA o el líder del equipo, que pueda validar los cambios solicitados contra toda la aplicación. Los cambios de esquema no deberían hacerse al azar.

Answer 5

¿No encuentra que las pruebas unitarias escritas para el código generalmente encuentran algún problema con el esquema de la base de datos?

Esto asume, por supuesto, que sus pruebas prueban todo.

Answer 6

He tenido que hacer este tipo de cosas antes, aunque no en C#.Para empezar, construí una herramienta de migración de esquemas, basada en la discusión al Ode to Code (page 1 of 5) (también hay herramientas existentes para hacer cosas similares). Es importante destacar que la herramienta de migración que construí te permitió especificar la base de datos a la que aplicabas los cambios y la versión que querías aplicar. Luego, siguiendo una primera metodología de prueba, cada vez que necesitaba hacer un cambio de esquema escribía un script de prueba que creaba una base de datos de prueba, aplicaba cambios de versión a la anterior a mi script de cambio de destino, agregaba algunos datos, aplicaba el script de cambio en probar y confirmar que los datos estaban en un estado esperado.

Mi objetivo principal con este fue confirmar que no hay datos se ha perdido o dañado durante las migraciones de esquema, no específicamente para comprobar que el esquema se encontraba en un estado en particular. Se requiere una buena conciencia de su conjunto de datos de producción, para que pueda escribir datos representativos de muestra para las pruebas.

Es debatible si esto se debe considerar la unidad de pruebas o pruebas de integración. Tiendo a considerarlo como una prueba de integración, basado en el hecho de que no quiero ejecutar pruebas antiguas cada vez que itero mi código. Como sea que quieras llamarlo, me pareció una herramienta útil para esa situación.