Est-il logique de rendre la classe de test unitaire statique?

Question

J'ai utilisé NDepend sur ma base de code et bien que mon code réel semble passer avec des couleurs volantes, mon code de test unitaire pourrait utiliser beaucoup de travail. L'une des suggestions faites à la dépendance a été de convertir bon nombre de mes classes de test unitaires en classes statiques en raison d'un degré élevé de séparation entre les tests. Il semble que cela pourrait aider à ne pas partager l'état entre les tests et leur permettre encore plus d'exécuter dans n'importe quel ordre. Dois-je convertir mes classes de test unitaires en classes statiques?

Partage de l'état entre les méthodes de test dans le même test de test et bien sûr entre les tests de test

Answer 1

Intrigant! Je n'ai jamais vu personne appliquer une analyse NDEPEND pour tester des projets auparavant. Bien que les tests unitaires doivent être considérés comme des citoyens de première classe de votre base de code, ils ne sont généralement pas déployés avec l'application et, en tant que tels, ne sont pas consultés avec les mêmes contraintes architecturales (FXCOP, NDEPEND, etc.). À un certain niveau, je suis d'accord avec cette approche, la qualité des tests doit être validée, mais je ne vois pas quel avantage qu'un outil peut fournir ici autre que d'identifier les préoccupations de couplage des classes qui seraient également identifiées dans le code de production.

En ce qui concerne Nunit, il instancie généralement une seule instance du TestFixture pour toutes les méthodes de test de cette classe de test. État est partagé entre les tests, et c'est bon et mauvais.

Bon: l'état qui prend du temps à créer peut être configuré lorsque le luminaire de test est configuré.

Mauvais: indiquez qui devrait être réinitialisé entre les tests, c'est à vous de résoudre entre les tests.

Si NUnit prend en charge les méthodes statiques pour les tests et si vous avez besoin d'un état dans le luminaire de test, ces champs devront être statiques. C'est en fait vraiment effrayant car l'état de vos tests est partagé pour la durée de vie de l'approdaine du test.

La clé consiste à utiliser les attributs Nunit pour le luminaire et le test d'initialisation / de démolition. N'utilisez jamais de constructeurs ou de finalisateurs pour l'initialisation du luminaire car vous ne pouvez pas contrôler lorsque le framework Nunit crée votre classe.

Answer 2

Si vos tests n'ont pas besoin d'exécuter dans un ordre particulier ou si ils ne dépendent pas du code d'initialisation, vous pouvez les rendre statiques.

N'oubliez pas que ce n'est pas une recette de réussite.