Comment tester la persistance unitaire?

Question

En tant que novice dans la pratique du développement piloté par les tests, je finissent souvent dans un dilemme quant à la façon de test de l'unité de persistance d'une base de données.

Je sais que, techniquement, ce serait un test d'intégration (pas une unité de test), mais je veux trouver les meilleures stratégies pour les éléments suivants:

1. Le test des requêtes.
2. Les tests inserts. Comment puis-je savoir que l'insert qui a mal tourné, en cas de panne? Je peux la tester en l'insertion et de l'interrogation, mais comment puis-je savoir que la requête n'était pas de mal?
3. Les tests de mises à jour et suppressions -- tests inserts

Quelles sont les meilleures pratiques pour faire ces?

---

Concernant les analyses SQL: je suis conscient que cela pourrait être fait, mais si j'utilise un O/R Mapper comme NHibernate, il s'attache à certains de nommage des verrues dans l'alias utilisé pour la sortie des requêtes, et que c'est un peu aléatoire, je ne suis pas sûr que je pourrais tester que.

Dois-je simplement, tout abandonner et de simplement faire confiance à NHibernate? Je ne suis pas sûr que c'est prudent de le faire.

Answer 1

Regarder en DB de l'Unité. C'est une bibliothèque Java, mais il doit y avoir un C# équivalent. Il vous permet de préparer la base de données avec un ensemble de données, de sorte que vous savez ce qui est dans la base de données, alors vous pouvez l'interface avec la DB de l'Unité de voir ce qui est dans la base de données. Il peut s'exécuter à l'encontre de nombreux systèmes de base de données, de sorte que vous pouvez utiliser votre base de données actuelle de l'installation, ou d'utiliser quelque chose d'autre, comme HSQL en Java (Java base de données de mise en œuvre avec une option de mémoire).

Si vous voulez tester votre code à l'aide de la base de données correctement (qui vous a le plus probable devrait être en train de faire), alors c'est le chemin à parcourir pour isoler chaque test et s'assurer de la base de données a prévu de données préparées.

Answer 2

Comme l'a dit Mike Stone , DbUnit est idéal pour mettre la base de données dans un état connu avant d'exécuter vos tests. Une fois vos tests terminés, DbUnit peut remettre la base de données dans son état antérieur à l'exécution des tests.

DbUnit (Java)

DbUnit.NET

Answer 3

Vous effectuez les tests unitaires en se moquant de la connexion de base de données. De cette façon, vous pouvez construire des scénarios où des requêtes spécifiques dans le flux d'un appel de méthode de réussir ou d'échouer. J'ai l'habitude de construire ma maquette attentes de façon à ce que le texte de la requête est ignorée, car j'ai vraiment envie de tester la tolérance de pannes de la méthode et la façon dont il gère lui-même-les spécificités de la SQL ne sont pas pertinents à cette fin.

Évidemment, cela signifie que votre test ne sera pas réellement vérifier que la méthode fonctionne, parce que le SQL trompe peut-être. C'est là que les tests d'intégration coup de pied dans. Pour cela, j'attends quelqu'un d'autre aura une plus approfondie de la réponse, comme je commence tout juste à se familiariser avec ces moi-même.

Answer 4

J'ai écrit un article ici concernant les tests unitaires de la couche de données qui couvre ce problème exact. Toutes mes excuses pour la prise (honteuse), mais l'article est trop long pour être publié ici.

J'espère que cela vous aide - cela a très bien fonctionné pour moi au cours des 6 derniers mois sur 3 projets actifs.

Cordialement,

Rob G

Answer 5

Le problème que j'ai connu lors de l'essai d'unité de persistance, surtout sans un ORM et, ainsi, se moquant de votre base de données (connexion), c'est que vous ne savez pas vraiment si vos requêtes de réussir. Il se pourrait que vous vos requêtes sont spécifiquement conçus pour une version de base de données et de réussir avec cette version. Vous ne trouverez jamais que si vous vous moquez de votre base de données. Donc, à mon avis, tests d'unité de persistance est que d'une utilité limitée. Vous devriez toujours ajouter des tests en cours d'exécution contre la base de données cible.