Voici une information qui peut surprendre. Le Framework que vous utilisez pour coder vos tests unitaires peut avoir un impact négatif sur votre couverture de code.

Ce n’est pas directement le Framework qui pose problème, mais la manière utilisée par les outils qui calculent le pourcentage de votre code qui est couvert par des tests. Ceux-ci incluent tous les projets compris dans votre solution. Ce qui comprend vos projets de test.

Si votre Framework de test est tel qu’il y a des codes qui ne seront jamais atteints, ces portions de code seront considérées comme non couvertes. Votre pourcentage de couverte du code baisse alors.

Comment peut-on avoir une portion de test qui n’est jamais atteinte ?

Exemple : si votre test doit déclencher une Exception, mais que votre Framework de test valide le teste au travers d’un attribut, le code qui est après l’Exception n’est pas couvert. Même s’il n’y a pas de code après. La simple accolade de fin de méthode ne peut pas être atteinte, car la méthode n’a pas pris fin normalement. Le code du test ne s’exécute donc pas à 100%.

Même si votre test est valide, l’approche de l’interception d’Exception ajoutée par un attribut réduit la couverture de code.

C’est le comportement que l’on constatera avec MSTest et son attribut ExpectedExceptionAttribute.

Pour ce type de tests, je préfère xUnit et sa méthode Assert.Throws(). 100% du code du test peut s’exécuter. La couverture de code n’est pas réduite.

Conclusion

Soyez vigilant lors du choix de votre Framework de tests, si la couverture de code est une métrique que vous prenez en considération (pour la qualité, le support ou lors de la conduite de vos projets).