exemple J'ai une classe de référentiel (dal): J'ai aussi une classe de service (BLL): Créer un test d'unité pour myRepository prendrait beaucoup plus de temps que de la mettre en œuvre, car je devrais me moquer de contexte de cadre d'entité. mais crée un test de l'unité Pour Myservice semble absurde, car il n'appelle que dans le référentiel. Tout ce que je pouvais vérifier est de vérifier si cela a fait une méthode de suppression de référentiel de référentiel. question Comment suggéreriez-vous à l'unité tester ces méthodes de suppression . Les deux? Un? Rien? Et que testeriez-vous?
5 Réponses :
Oui, les deux.
IMyRepository mock = ...; // create Delete(int) expectation MyService service = new MyService(mock); service.Delete(100); // Verify expectations
Eh bien, tout ce que vous avez fait dans votre exemple était un test de service.Delete (). Vous vous moquez mon référentiel et votre service testé qu'il appelle réellement au référentiel.
Ce que je voulais dire avec mon commentaire précédent, c'est que vous avez dit "à la fois" mais seulement écrit du code pour tester la couche de service. Mais oui, le service est testé dans votre cas.
Désolé Oui, j'aurais alors un autre ensemble de tests pour tester le référentiel concret, qui peut être plus difficile puisque vous dépendez probablement des bibliothèques tierces et d'autres couches. Ces tests peuvent finir par être plus comme des tests d'intégration. Donc, les deux, recherchent une couverture totale de code. Mais je ne pense pas que vous puissiez négliger cette classe puisqu'il s'agit d'abstraction que vous codez votre application.
Créer le test du service. actuellement tout ce qu'il fait est d'appeler dans la méthode de suppression du référentiel; Cependant, vous ne devriez pas vous soucier de cela. Et si plus tard quelque chose se passe et que la fonctionnalité devient beaucoup plus compliquée? Vous ne voulez pas avoir de code de test unitaire qui vous assurera que la fonctionnalité fonctionne toujours comme prévu?
Si vous exposez votre Supprimer par votre service, vous vous attendez à ce que cela ait un effet. Écrivez un test unitaire pour tester cet effet. En fonction de vos besoins particuliers, je dirais que vous n'avez peut-être pas besoin d'un test sur le référentiel Supprimer, en particulier si cette fonctionnalité se fait exercer dans le cadre de votre fonctionnalité de suppression de service, mais cela dépend vraiment du niveau de la couverture en essayant.
Mais si j'appuie une méthode de test de test.Delete (), tout ce que je peux faire est de vérifier que cela appelle son référentiel.Delete (). Je ne peux vérifier aucune donnée, car la manipulation de données est effectuée dans le référentiel.
Est-il suffisant de savoir que le service.delete () appelle le référentiel.delete ()? Ensuite, tu vas bien avec juste service.delete (). Avez-vous besoin de vérifier les données? Ensuite, vous aurez besoin d'un certain niveau de moqueur pour vérifier que les données sont modifiées.
Oui, j'écris certainement un test d'unité pour la couche de service. La raison en est que, vous n'êtes pas seulement testant que votre mise en œuvre fonctionne maintenant, mais vous testez également qu'il continuera de travailler à l'avenir.
C'est un concept vital pour comprendre. Si quelqu'un vient plus tard et change votre serviceLayer, et il n'y a pas de test de l'unité, comment pouvez-vous vérifier que la fonctionnalité continue de fonctionner?
J'écrirais également des tests pour votre dal, mais je les mettreais dans une assemblée séparée appelée DataTest ou quelque chose. Le but ici est d'isoler vos préoccupations entre les assemblées. Les tests unitaires ne devraient pas être concernés par votre dal, vraiment.
Mais si j'appuie une méthode de test de test.Delete (), tout ce que je peux faire est de vérifier que cela appelle son référentiel.Delete (). Je ne peux vérifier aucune donnée, car la manipulation de données est effectuée dans le référentiel. D'autres complexités (futures) ne seront pas incluses dans le test.
@Robert qui n'est pas entièrement correct. Vous auriez besoin de créer un objet imyréposteur similiçant. Une fois que vous avez fait cela, vous pouvez configurer votre moqueur de sorte que lorsque la couche de service appelle de l'appelle, vous pouvez vérifier que la suppression est appelée correctement sur la maquette. Par conséquent, vous testez la fonctionnalité Service.Delete sans tester le référentiel.Delete aussi.
En outre, si vous aviez créé ce code avec TDD, vous auriez eu un test. En fait, cela compte si les gens peuvent appeler supprimer votre service, vous devez donc le tester.
À mon avis, vous devez tester les deux. Peut-être que vous pouvez faire la classe de contexte Création EF dans une usine séparée pouvant être testée plus facile et se moquer de la classe de contexte pour les tests myRepository. Ce sera plus facile et utiliser une usine pour créer un contexte d'appels semble être calme utile pour moi.
Je voudrais, mais comme je peux google sur le fond de l'entité nette, le contexte de l'entité moqueur est une douleur dans l'A ...