Tests d'intégration de base de données

Question

Lorsque vous effectuez des tests d'intégration avec uniquement votre couche d'accès aux données ou la majorité de la pile d'applications. Quel est le meilleur moyen d’empêcher que plusieurs tests s’entrechoquent s’ils sont exécutés sur la même base de données?

Answer 1

Transactions.

La structure de test unitaire de ruby ??on rails est la suivante:

Load all fixture data.

For each test:

  BEGIN TRANSACTION

    # Yield control to user code

  ROLLBACK TRANSACTION

End for each

Cela signifie que

1. Les modifications apportées par votre test à la base de données n'affecteront pas les autres threads tant qu'il est en cours
2. Les données du prochain test ne sont pas polluées par des tests antérieurs
3. Cela représente environ un million de fois plus rapide que le rechargement manuel des données pour chaque test.

Je pense que c'est plutôt cool

Answer 2

Pour les applications de base de données simples, je trouve que SQLite est inestimable. Il vous permet d’avoir une base de données unique et autonome pour chaque test.

Cependant, cela ne fonctionne que si vous utilisez une fonctionnalité SQL générique simple ou si vous pouvez facilement cacher les légères différences entre SQLite et votre système de base de données de production derrière une classe, mais j'ai toujours trouvé que c'était assez facile dans les applications SQL. J'ai développé.

Answer 3

Juste pour ajouter à la réponse de Free Wildebeest, j’ai également utilisé HSQLDB pour effectuer un test de type similaire dans lequel chaque test est obtenu. une instance propre de la base de données.

Answer 4

Je voulais accepter les réponses de Free Wildebeest et d’Orion Edwards, mais cela ne me le permettait pas. La raison pour laquelle je voulais faire cela, c’est que j’en arrivais à la conclusion que c’étaient les deux façons principales de le faire, mais celle à choisir dépendait du cas individuel (principalement la taille de la base de données).

Answer 5

Exécutez également les tests à des moments différents, afin qu'ils n'aient pas d'incidence sur les performances ou la validité des autres.

Answer 6

Même si elle n’est pas aussi astucieuse que le cadre de tests unitaires Rails dans l’une des autres réponses données ici, la création de données distinctes par test ou groupe de tests est une autre façon de procéder. Le niveau d’ennui associé à cette solution dépend du nombre de cas de test que vous avez et de leur dépendance les uns aux autres. Si vous avez une base de données par test ou par groupe de tests dépendants, la pénibilité reste vraie.

Lors de l'exécution de la suite de tests, vous chargez les données au début, exécutez la suite de tests, déchargez / comparez les résultats en vous assurant que le résultat réel correspond au résultat attendu. Sinon, recommencez le cycle. Charger, exécuter la suite, décharger / comparer.