Les assertions multiples sont-elles mauvaises dans un test unitaire ? Même en cas de chaînage ?

Question

Y a-t-il un problème à vérifier autant de choses dans ce test unitaire ?

ActualModel = ActualResult.AssertViewRendered()        // check 1
                          .ForView("Index")            // check 2
                          .WithViewData<List<Page>>(); // check 3

CollectionAssert.AreEqual(Expected, ActualModel);      // check 4

Les principaux objectifs de ce test sont de vérifier que la bonne vue est renvoyée (vérification 2) et qu'elle contient les bonnes données (vérification 4).

Est-ce que je gagnerais quelque chose en divisant cette épreuve en plusieurs tests ? Je suis tout à fait d'accord pour faire les choses correctement, mais je ne vais pas diviser les choses si cela n'a pas de valeur pratique.

Je suis assez novice en matière de tests unitaires, alors soyez indulgent.

Answer 1

Comme d'autres l'ont souligné, il est préférable de s'en tenir à une seule assertion dans chaque test afin d'éviter de perdre des informations - si la première assertion échoue, vous ne savez pas si les suivantes échoueront également. Vous devez résoudre le problème avec moins d'informations, ce qui pourrait être (sera probablement) plus difficile.

Une très bonne référence est l'ouvrage de Roy Osherove intitulé L'art des tests unitaires - Si vous voulez vous lancer dans les tests unitaires, vous pouvez faire bien pire que de commencer ici.

Answer 2

Notant pour les futurs lecteurs que cette question et son double Est-ce une mauvaise pratique d'avoir plus d'une assertion dans un test unitaire ? ont des opinions majoritaires opposées, alors lisez les deux et décidez par vous-même.

Mon expérience est que le quantum de test le plus utile n'est pas l'assertion, mais le scénario -- c'est-à-dire qu'il devrait y avoir un test unitaire pour un ensemble donné de conditions initiales et d'appel de méthode, avec autant d'assertions que nécessaire pour affirmer les conditions finales attendues. Avoir un test unitaire par assertion conduit à une configuration dupliquée ou à des solutions de contournement tortueuses pour éviter la duplication (comme les affreux contextes rspec profondément imbriqués que je vois de plus en plus ces derniers temps). Cela multiplie également les tests, ce qui ralentit considérablement votre suite.

Answer 3

Tant que chaque assertion possède un message d'échec unique et identifiable, vous devriez être en mesure d'éviter tout problème de roulette des assertions, car il ne sera pas difficile de savoir quel test a échoué. Faites preuve de bon sens.

Answer 4

J'ai trouvé un argument différent à cette question (du moins pour moi) :

L'utilisation de plusieurs assertions est acceptable si elles testent la même chose.

Par exemple, c'est OK de faire :

Assert.IsNotNull(value);
Assert.AreEqual(0, value.Count);

Pourquoi ? parce que ces deux assertions ne cachent pas l'intention du test. Si la première assertion échoue, cela signifie que la seconde échouera aussi. Et en effet, si nous supprimons la première assertion, la deuxième assertion échoue (avec une exception de référence nulle - ! !!) de toute façon lorsque la fonction value est nulle. Si ce n'était pas le cas, alors nous ne devrions pas mettre ces deux assertions ensemble.

Donc, c'est faux :

Assert.IsNotNull(value1);
Assert.IsNotNull(value2);

Comme je l'ai mentionné plus haut, si la première assertion échoue, il n'y a pas d'indication claire concernant la seconde assertion - nous voudrions toujours savoir ce qu'il advient de la seconde ( même si le premier a échoué ). Ainsi, pour cette raison, ces deux assertions appartiennent à deux tests unitaires différents.

Conclusion : mettre une ou plusieurs assertions, lorsqu'il est fait correctement Dans ce cas, la question est de savoir si nous voulons voir les exceptions relatives aux assertions dans les résultats des tests, ou si nous voulons voir d'autres exceptions dans des cas particuliers.

Answer 5

Il est préférable de s'en tenir à une seule assertion dans chaque test afin d'éviter La roulette des assertions .

Si vous devez configurer le même scénario pour tester plusieurs conditions basées sur des prémisses identiques, il est préférable d'extraire le code de configuration vers une méthode d'aide partagée, puis d'écrire plusieurs tests qui appellent cette méthode d'aide.

Cela garantit que chaque scénario de test ne teste qu'une seule chose.

Comme toujours, il y a des exceptions à cette règle, mais puisque vous êtes nouveau aux tests unitaires, je vous recommande de vous en tenir à l'outil une assertion par test unitaire jusqu'à ce que vous ayez appris quand vous pouvez vous écarter de la règle.