¿Cómo pruebo las migraciones de bases de datos?

Question

Estoy usando Migrator.NET para escribir las migraciones de la base de datos para la aplicación. Marc-André Cournoyer escribió:

Al igual que cualquier código de la aplicación que debe probar sus migraciones. Código de subidas y bajadas. Hágalo parte de su proceso de compilación continua y pruébelo en tantas bases de datos diferentes como como sea posible.

¿Cómo puedo hacer eso? Digamos que tengo el método Up() que crea una tabla y el método Down() que descarta la misma tabla y estoy usando SQL Server. ¿Cómo se vería una prueba? ¿Debo ejecutar consultas SQL en las tablas del sistema, como select * from sys.columns, para verificar si la tabla fue creada y que tiene la estructura adecuada? ¿Qué pasa si estamos usando NHibernate?

EDITAR me refiero a las migraciones en el sentido Rails ActiveRecord migraciones (crear, modificar y derribando bases de datos en pequeños pasos basados ​​en código C#).

EDIT 2 Y here 's donde leí acerca de que debemos probar las migraciones. La publicación del blog en realidad está vinculada desde la wiki de Migrator.

Answer 1

¿Usted prueba su DAL - algún tipo de prueba de integración?

Necesita más que un script de migración, también necesita un script de línea base. Cuando desee probar una actualización de la base de datos, debe ejecutar todas las secuencias de comandos de la línea de base en un servidor de pruebas/etapas para crear la versión más nueva de la base de datos. Luego, pruebe su DAL con la base de datos de prueba actualizada. Si todas las pruebas DAL tienen éxito, entonces su migración debería haber sido exitosa (de lo contrario, sus pruebas DAL no son lo suficientemente completas).

Es una prueba cara de ejecutar, pero es casi sólida como una roca. Personalmente admitiré hacer mucho de esto manualmente en este momento; tenemos una herramienta de migración interna que aplicará todos los scripts (incluida la línea de base), por lo que la configuración de la base de datos de prueba y las pruebas DAL son pasos separados. Sin embargo, funciona Si desea asegurarse de que se creó una tabla, ¡no hay mejor método que tratar de insertar datos en ella!

Puede intentar verificar los resultados mirando catálogos del sistema y INFORMATION_SCHEMA puntos de vista y así sucesivamente, pero en última instancia, la única manera de estar seguro de que es en realidad trabajando es tratar de uso los nuevos objetos. El hecho de que los objetos estén allí no significa que sean funcionales.

Answer 2

tal vez este scrip puede ayudarle a:

http://www.benzzon.se/forum/uploads/benzzon/2006-03-27_134824_sp_CompareDB.txt

este script comparar dos db (estructura y datos)

Answer 3

control Fuente es para tomar una instantánea de la base de código actual.. La migración es para cambiar su base de datos de una versión a otra. De modo que en algún momento futuro pueda tomar una base de datos anterior, aplicar migraciones y trabajar con la última base de códigos.

Nunca he visto las migraciones reales probadas. He visto los resultados probados, y me han pillado/me recordaron que ejecutara las últimas migraciones.

describe User do 
    it { should have_column :name, :type => :string } 
    it { should validate_presence_of :name}  
end 

Así que alguien cambia el modelo. Agrega una prueba para reflejar el modelo. Agrega la migración Luego confirma la fuente.
Usted toma las últimas pruebas de ejecución. Las pruebas fallan porque la base de datos no se corresponde. Recuerda ejecutar migraciones, luego vuelva a ejecutar las pruebas. Éxito.

Answer 4

Usted PODRÍA hacer una comparación de los objetos del sistema de la base de datos, pero tendría que tener un objetivo contra el cual comparar; de lo contrario, ¿cómo saber si se aprobó o no?

Creo que será mejor que cree un conjunto de casos de prueba de operación CRUD de caja de borde que ejercitan las entidades u operaciones en la capa de datos. Si alguno de estos falla, la base de datos no está sincronizada con lo que se requiere. es decir, si la inserción de un campo char (20) falla porque solo es char (15) en la base de datos. Entonces se puede hacer la comparación de la estructura db para ver qué sucede si está apagado.

Es posible que pueda cortocircuitar esto al centrarse solo en los elementos recientemente modificados y suponiendo que se han aplicado cambios anteriores.

Answer 5

Trate las pruebas de migración como parte de su estrategia general de prueba de persistencia si utiliza NHibernate, es decirsi puede crear y guardar todas sus entidades sin ningún error, su base de datos y sus asignaciones deberían ser correctas.

Answer 6

Estoy buscando una respuesta a esto también. Creo que esto debería probarse en un entorno de integración en lugar de uno de prueba de unidad: para las pruebas de unidad (DAL) dejo caer la base de datos y la vuelvo a crear.

Sin embargo, idealmente me gustaría tener un entorno de integración donde mi base de datos se reproduzca desde la producción y las secuencias de comandos de migración DB en ambos sentidos: hacia arriba para asegurar una actualización suave de la producción y hacia abajo para asegurar que las reversiones sean posibles.