Y a-t-il trop d'affirmations dans ce test unitaire? Je ne pense pas que ce code nécessite une explication, mais si c'est le cas s'il vous plaît faites le moi savoir.Y a-t-il trop d'affirmations dans ce test unitaire?
J'essaie de garder mes UnitTests relativement petits et de tester une chose à la fois. Donc, je ferais probablement tester des parties distinctes dans des tests séparés, par ex.
sendWillSendAnEmail,fromContainsSenderAddress,toContainsRecipientAddress,mailBodyContainsMailMessage,mailContainsSubjectMais ne vous retrouvez-vous pas avec beaucoup de code répété ou beaucoup de code infrastructure-y pour mettre en place ces différents tests? ça en vaut vraiment la peine? – Arlen
@Arlen: Mon unité teste la tente pour avoir un peu de code répété, mais gardez-le au minimum en utilisant des méthodes d'usine pour la configuration du test et des méthodes Assert personnalisées. L'astuce consiste à minimiser la duplication de code pour assurer la maintenabilité, mais aussi assurer la lisibilité. C'est l'art des tests unitaires :-) – Steven
@Arlen Habituellement, soit je configure ce qui est nécessaire dans la méthode d'installation, de sorte qu'il soit disponible dans n'importe quel test ou que j'écrive un assistant pour définir l'état - quel que soit le code. Cela fonctionne plutôt bien et avec très peu de duplication de code pour moi. Vous n'avez pas ajouté de balise de langue à votre question, je dois donc noter que j'utilise PHPUnit. PHPUnit est un framework xUnit donc je suppose que la même chose devrait être possible avec votre framework. – Gordon
Non en général, plus les affirmations sont nombreuses, mieux c'est. Une erreur courante dans les tests unitaires n'est pas assez explicite.
Votre test est très explicite et lisible. J'aime particulièrement les assertions sur null. C'est une bonne pratique car cela rend l'interprétation d'un échec de test extrêmement simple. La seule façon d'avoir trop d'assertions est d'affirmer exactement la même chose plus d'une fois, ce que vous ne faites pas.
Je ne vois aucun problème particulier avec votre affirme, mais si vous voulez nettoyer votre code, vous pouvez changer
var session = server.Sessions.FirstOrDefault();
Assert.NotNull(session);
dans
var session = server.Sessions.First();
First() lèveront une exception de toute façon, par juste en changeant votre code vous obtenez le bénéfice que l'affirmation vous apporterait sans autant de code. Il y a d'autres endroits où vous pouvez faire des changements similaires aussi.
Mais en règle générale, ne tenez rien pour acquis dans les tests unitaires - et cela signifie beaucoup d'affirmations!
Cela dépend des normes auxquelles vous adhérez, mais je dirais généralement que oui, vous avez beaucoup trop d'affirmations dans ce test.
Beaucoup de gens soutiennent qu'un seul test devrait avoir un seul assert; Je pense que cela peut être un peu exagéré, mais je crois certainement qu'il est approprié d'avoir un seul test unitaire pour un seul morceau de fonctionnalité; vous êtes partout avec vos affirmations. Le test est trop grand; divisez-le en plusieurs tests différents.
Je pense que la question est de savoir si les assert() les valeurs d changent de façon indépendante? Si elles changent indépendamment, alors ils devraient être testés dans différents tests qui varient les conditions liées à chaque affirmation.
Si toutefois vous avez un seul chemin de code qui génère un e-mail avec tous ces champs, alors tester toutes ces choses dans un test est approprié.
Maintenant, le test est difficile à lire. Vous pouvez inclure ces affirmations dans une méthode d'aide descriptive. Je ne m'en soucierais pas tant que je n'aurais pas trouvé la même méthode d'aide utile ailleurs.
Je pense que c'est trop grand. Quand vous avez un tas de tests plus petits, vous pouvez obtenir la localisation des défauts - juste en exécutant tous les tests, vous pouvez voir exactement où un problème est. Avec autant d'affirmations que vous avez actuellement (et pas de messages d'affirmation), vous devrez probablement lancer un débogueur pour le savoir. Rappelez-vous que vous finirez probablement par avoir des centaines sinon des milliers de tests, et si un tas d'entre eux échouent, vous ne voulez pas avoir à déboguer chacun pour voir pourquoi.
De plus, toute affirmation échouant au début du test signifie que les assertions ultérieures ne sont pas exécutées. Quand ils sont séparés en tests individuels, chaque affirmation est vérifiée. C'est une sorte de compromis; Beaucoup de ces affirmations sont probablement liées et échoueront en même temps, donc vous aurez cinq tests rouges au lieu d'un. Mais je part du principe que plus d'informations sont meilleures, donc je préférerais avoir ces cinq tests et savoir que les cinq affirmations ont échoué.
Vos nombreuses affirmations sont un indicateur de la quantité de logique que vous avez dans les tests unitaires. Vous allez devoir maintenir vos tests unitaires comme du code ordinaire. Il est préférable de passer du temps sur la programmation défensive et la programmation par contrat plutôt que de coder des tests unitaires.
Peut-être que vous pouvez créer une nouvelle classe Email qui accepte tous ces paramètres dans son constructeur par défaut.
Et puis vous pouvez lancer une exception dans le cas où l'utilisateur passe un paramètre non valide.
Et dans votre test unitaire
Send_sends_an_email_message
vous pouvez ajouter les contrôles affirme que égalités seulement au lieu de vérifier contre NULLs.
Peut-être que vous pouvez créer 2 emails dans un test et faire les affirmations d'égalité pour les deux instances.
Oui, vous avez trop d'affirmations dans votre code! De plus, la déclaration assert devrait être seulement une par méthode de test. L'utilisation de nombreuses affirmations peut être l'odeur de code que vous testez plus d'une chose. De plus, il y a une chance que quelqu'un puisse ajouter une nouvelle affirmation à votre test au lieu d'en écrire un autre. Et comment pouvez-vous comprendre comment vos autres affirmations terminées lorsque le premier a échoué?
Vous pourriez également trouvé intéressant ce post: https://timetocode.wordpress.com/2016/06/01/zen-of-unit-testing/
Juste une chose à dire. Lisez ce livre: http://www.amazon.com/Art-Unit-Testing-Examples-Net/dp/1933988274. Vous serez un autre développeur après l'avoir lu. – Steven
@Steven: Je vais le lire; Je vous remercie. – Arlen