Comment faire de test de l'unité de persistance?

StackOverflow https://stackoverflow.com/questions/2046

  •  08-06-2019
  •  | 
  •  

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.

Était-ce utile?

La solution

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.

Autres conseils

Comme Mike Pierre a dit, DbUnit est idéal pour obtenir la base de données dans un état connu avant l'exécution de vos tests.Lors de vos tests sont finis, DbUnit pouvez mettre la base de données de retour dans l'état où il était avant l'exécution des tests.

DbUnit (Java)

DbUnit.NET

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 sorte que le texte de la requête réelle 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, car je suis commence tout juste à se familiariser avec ces moi-même.

J'ai écrit un post ici concernant unité de test de la couche de données qui couvre exactement ce problème.Excuses pour l' (honteux) plug, mais l'article est trop long pour le poster ici.

J'espère que vous aide - il a très bien fonctionné pour moi au cours de la dernière 6 mois sur 3 projets actifs.

En ce qui concerne,

Rob G

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.

Pour NHibernate, Je serais certainement plaider juste se moquant de la NHibernate API pour les tests unitaires -- faire confiance à la bibliothèque pour faire la bonne chose.Si vous voulez vous assurer que les données qui se passe réellement dans la bd, faire un test d'intégration.

Pour JDBC en fonction des projets, mon Acolyte cadre peut être utilisé: http://acolyte.eu.org .Il permet de maquette d'accès aux données que vous souhaitez tests, bénéficiant de JDBC abstraction, sans avoir à gérer un test spécifique DB.

Je voudrais aussi se moquer de la base de données, et de vérifier que les requêtes sont ce que vous attendiez.Il y a le risque que le test vérifie le mauvais sql, mais ce serait détecté dans les tests d'intégration

Techniquement tests d'unité de persistance ne sont pas des tests Unitaires, ils sont les tests d'Intégration.

Avec C# à l'aide de mbUnit, vous utilisez simplement la SqlRestoreInfo et la Restauration des attributs

    [TestFixture]
    [SqlRestoreInfo(<connectionsting>, <name>,<backupLocation>]
    public class Tests
    {

        [SetUp]
        public void Setup()
        {

        }

        [Test]
        [RollBack]
        public void TEST()
        {
           //test insert. 
        }
    }

La même chose peut être réalisé dans NUnit, excepeté les noms d'attributs diffèrent légèrement.

Comme pour vérifier si votre requête a été succeful, vous devez normalement faire suivre d'une seconde requête pour voir si la base de données a été modifiée comme vous vous attendez.

J'ai l'habitude de créer un référentiel et l'utiliser pour enregistrer mon entité, puis récupérer un nouveau.Puis-je affirmer que l'extrait est égale à la sauvé.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top