Je crée généralement un référentiel et l'utilise pour enregistrer mon entité, puis en récupérer une nouvelle. Ensuite, j'affirme que le récupéré est égal au sauvegardé.
En tant que novice dans la pratique du développement piloté par les tests, je me retrouve souvent dans un dilemme quant à la façon de tester unitairement la persistance d'une base de données.
Je sais que techniquement, il s'agirait d'un test d'intégration (et non d'un test unitaire), mais je souhaite découvrir les meilleures stratégies pour les éléments suivants :
Quelles sont les meilleures pratiques pour faire cela ?
En ce qui concerne les tests SQL : je suis conscient que cela pourrait être fait, mais si j'utilise un mappeur O/R comme NHibernate, il attache des verrues de nommage dans les alias utilisés pour les requêtes de sortie, et comme c'est quelque peu imprévisible, je ' Je ne suis pas sûr de pouvoir tester cela.
Dois-je tout abandonner et simplement faire confiance à NHibernate ? Je ne suis pas sûr que ce soit prudent.
Je crée généralement un référentiel et l'utilise pour enregistrer mon entité, puis en récupérer une nouvelle. Ensuite, j'affirme que le récupéré est égal au sauvegardé.
Regardez dans DB Unit. C'est une bibliothèque Java, mais il doit y avoir un C
Techniquement, les tests unitaires de persistance ne sont pas des tests unitaires, ce sont des tests d'intégration.
Avec C
Pour NHibernate
, je recommanderais certainement de simplement se moquer du NHibernate API
pour les tests unitaires - faites confiance à la bibliothèque pour faire ce qu'il faut. Si vous voulez vous assurer que les données vont bien dans la base de données, faites un test d'intégration.
Le problème que j'ai rencontré lors des tests unitaires de persistance, en particulier sans ORM et donc en se moquant de votre base de données (connexion), est que vous ne savez pas vraiment si vos requêtes réussissent. Il se peut que vos requêtes soient spécifiquement conçues pour une version de base de données particulière et ne réussissent qu'avec cette version. Vous ne le découvrirez jamais si vous vous moquez de votre base de données. Donc, à mon avis, la persistance des tests unitaires n'a qu'une utilité limitée. Vous devez toujours ajouter des tests exécutés sur la base de données ciblée.
Je me moquerais également de la base de données et vérifierais que les requêtes correspondent à ce que vous attendiez. Il y a un risque que le test vérifie le mauvais sql, mais cela serait détecté dans les tests d'intégration
Vous effectuez les tests unitaires en simulant la connexion à la base de données. De cette façon, vous pouvez créer des scénarios dans lesquels des requêtes spécifiques dans le flux d'un appel de méthode réussissent ou échouent. Je construis généralement mes attentes fictives afin que le texte de la requête réelle soit ignoré, car je veux vraiment tester la tolérance aux pannes de la méthode et comment elle se gère elle-même - les spécificités du SQL ne sont pas pertinentes à cette fin.
Évidemment, cela signifie que votre test ne vérifiera pas réellement que la méthode fonctionne, car le SQL peut être erroné. C'est là que les tests d'intégration entrent en jeu. Pour cela, je m'attends à ce que quelqu'un d'autre ait une réponse plus approfondie, car je commence tout juste à les maîtriser moi-même.