Comment tester les migrations de base de données?

Question

J'utilise Migrator.NET pour écrire des migrations de base de données pour l'application. Marc-André Cournoyer a écrit:

Comme tout code dans votre application, vous devez tester vos migrations. Le code des hauts et des bas. Faites-le partie de votre processus de construction continue et testez-le sur autant de bases de données différentes et environnement que vous le pouvez.

Comment faire? Dites que j'ai la méthode Up() qui crée une table et la méthode Down() qui supprime la même table et j'utilise SQL Server. À quoi ressemblerait un test? Dois-je exécuter une requête SQL sur les tables système, comme select * from sys.columns, pour vérifier si la table a été créée et qu'elle a la structure appropriée? Et si nous utilisons NHibernate?

EDIT je veux dire les migrations dans les rails ActiveRecord sens des migrations (créer, modifier et démolissant les bases de données en petites étapes sur la base du code C#).

EDIT 2 Et here « s où je lis que nous devrions tester les migrations. L'article du blog est en fait lié depuis le wiki de Migrator.

Answer 1

Testez-vous votre DAL - une sorte de test d'intégration?

Vous avez besoin de plus d'un script de migration, vous avez également besoin d'un script de base. Lorsque vous souhaitez tester une mise à niveau de base de données, vous devez exécuter tous les scripts à partir de la ligne de base sur un serveur de test/de transfert pour créer la version la plus récente de la base de données. Ensuite, testez votre DAL par rapport à la base de données de test mise à jour. Si tous les tests DAL réussissent, votre migration devrait avoir réussi (sinon vos tests DAL ne sont pas assez complets).

C'est un test coûteux à faire tourner, mais il est assez solide. Personnellement, je vais avouer que j'en fais beaucoup manuellement pour le moment. Nous disposons d'un outil de migration interne qui appliquera tous les scripts (y compris la ligne de base), de sorte que la configuration de la base de données de test et les tests DAL sont des étapes distinctes. Cela fonctionne bien. Si vous voulez vous assurer qu'une table a été créée, il n'y a pas de meilleure méthode que d'essayer d'y insérer des données!

Vous pouvez essayer de vérifier les résultats en consultant les catalogues système et INFORMATION_SCHEMA vues et ainsi de suite, mais en fin de compte la seule façon d'être sûr qu'il est en fait travaille est d'essayer d'utiliser les nouveaux objets. Juste parce que les objets sont là ne signifie pas qu'ils sont fonctionnels.

Answer 2

peut-être ce scrip peut vous aider:

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

ce script comparer deux db (structure et données)

Answer 3

contrôle de la source est de prendre un instantané de votre base de code actuel.. La migration consiste à déplacer votre base de données d'une version à l'autre. Pour qu'à un moment donné vous puissiez prendre une ancienne base de données, appliquer des migrations et travailler avec la base de code la plus récente.

Je n'ai jamais vu les migrations réelles testées. J'ai vu les résultats testés, et ils m'ont attrapé/rappelé de faire les dernières migrations.

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

Alors quelqu'un change le modèle. Ajoute un test pour refléter le modèle. Ajoute la migration. Puis valide la source.
Vous obtenez les derniers tests. Les tests échouent car la base de données ne correspond pas. Vous vous souvenez d'exécuter des migrations, puis de relancer les tests. Succès.

Answer 4

Vous POUVEZ faire une comparaison des objets système de base de données, mais vous auriez besoin d'une cible par rapport à laquelle comparer - sinon comment sauriez-vous si passé ou échoué?

Je pense que vous feriez mieux de créer un ensemble de cas de test d'opération CRUD de casse qui exercent les entités ou les opérations dans la couche de données. Si l'un d'entre eux échoue, la base de données n'est pas synchronisée avec ce qui est requis. c'est-à-dire si l'insertion d'un champ char (20) échoue parce que c'est uniquement char (15) dans la base de données. Ensuite, la comparaison de structure db peut être faite pour voir si elle est désactivée.

Il se peut que vous puissiez court-circuiter cette fonction en vous concentrant uniquement sur les éléments modifiés récemment et en supposant que des modifications ont déjà été effectuées.

Answer 5

Traitez les tests de migration dans le cadre de votre stratégie globale de test de persistance si vous utilisez NHibernate, par exemple.Si vous pouvez créer et sauvegarder toutes vos entités sans aucune erreur, votre base de données et vos correspondances doivent être correctes.

Answer 6

Je cherche une réponse à cela aussi. Je pense que cela devrait être testé dans un environnement d'intégration plutôt que dans un environnement de test unitaire: Pour les tests unitaires (DAL), je laisse tomber la base de données et la recréer. Cependant, idéalement, je voudrais avoir un environnement d'intégration où ma base de données est répliquée depuis la production et les scripts de migration DB s'exécutent dans les deux sens: Pour assurer une mise à niveau progressive de la production et vers le bas pour garantir des restaurations.