Comment structurez-vous vos tests NUnit sur un grand projet?

Question

Je souhaite voir si je peux améliorer la façon dont nous utilisons NUnit dans une solution Visual Studio contenant plus de 30 projets.

Premièrement, auriez-vous un assemblage de tests pour chaque assemblage de la solution ou tenteriez-vous de limiter le nombre d'assemblages de test? J'ai commencé par créer de nombreux assemblages de test, mais je pense que cela nous coûte cher en termes de temps de construction.

Deuxièmement, quelle stratégie utilisez-vous pour gérer les tests de longue durée ou nécessitant une configuration d'environnement particulière? J'aimerais écrire un script MSBuild qui automatise l'exécution de nos tests unitaires, mais il doit ignorer les tests qui prendraient trop de temps ou ne fonctionneraient pas sur la machine de construction.

Answer 1

Pour répondre à votre première question:

Vous pouvez utiliser les catégories pour que tout soit organisé dans un assemblage unique si c'est comme ça que vous voulez aller. Quant à savoir si cela réduirait le temps de construction, je devinerais peut-être, je ne pense pas que ce serait une somme énorme dans l'ensemble.

Pour répondre à votre seconde:

Vous pouvez utiliser les catégories et le [Explicit] et [Ignorer] attribue à NUnit les tests à exécuter, et quels tests vous devez lui dire d'exécuter avant qu'il ne le fasse. Vous pouvez également consulter [Plate-forme] ou certains autres attributs, en fonction de vos exigences exactes en matière d'environnement.

Par exemple, vous pouvez ajouter une balise Explicit à tous vos tests longs. Ensuite, vous devrez exécuter ces tests explicitement, NUnit ne les exécutera pas automatiquement. Ou ajoutez tous ces tests à une catégorie, puis, lorsque vous exécutez NUnit, indiquez-lui explicitement de ne pas exécuter cette catégorie.

Answer 2

Pour votre cas, je vous donnerais quelques options:

• Consolidez vos projets existants pour en réduire le nombre, consolidant ainsi les projets de test correspondants . Essayez de penser si vous avez réellement besoin de 30 projets (par exemple, 30 ensembles) ou s'il vaut mieux combinez-les simplement pour réduire le nombre de dépendances et le temps de construction.

• Mettez vos tests dans le projet correspondant - Bien que cela puisse déclencher une réaction violente, réfléchissez-y: compte tenu du nombre important de tests, il peut être fastidieux d'obtenir un assemblage légèrement plus grand. Cela valait la peine de gérer deux fois plus de projets que nécessaire.

• Combinez tous les tests unitaires dans quelques projets : si vous tenez à ce que chaque assemblage soit propre et séparé, vous pouvez simplement choisir de combiner tous les tests unitaires, probablement en termes de pertinence les uns avec les autres.

Par conséquent, vous pouvez également faire des configurations de solution qui n'incluent pas de tests unitaires, si le temps de construction vous préoccupe tellement. Ceci est particulièrement utile si vous exécutez des tests à la demande . Si vous utilisez l'intégration continue, cela ne devrait pas poser de problème: vous pouvez avoir plusieurs configurations de CI, certaines comprenant des tests de construction, d'autres non.

Answer 3

C’est une excellente question qui soulève quelques inquiétudes sur la gestion d’un grand nombre de tests unitaires pour les grands projets de longue durée.

Ma stratégie consiste à avoir un projet de test unitaire pour chaque projet de votre solution lié à l'entreprise ou au framework. Les tests unitaires sont peu adaptés pour tester les aspects d'interface utilisateur d'un projet et je laisse généralement cette tâche à des tests simplifiés. Le projet est construit à l'aide d'un serveur d'intégration continue (CI) qui est déclenché à chaque fois qu'un développeur valide une partie du travail. Le serveur CI exécute également tous les tests unitaires et génère des statistiques de couverture de tests unitaires. L’environnement CI utilise MSBuild pour générer la solution.

Au fil du temps, il est utile d’évaluer si tous vos tests unitaires sont nécessaires. Une grande partie de l'effort de test de régression passera désormais à un test par script et la charge de maintenance des tests unitaires peut être coûteuse. Idéalement, je souhaiterais que tous les tests unitaires soient maintenus pendant toute la durée du projet, mais les frais généraux de maintenance peuvent parfois être prohibitifs. En règle générale, des tests unitaires sont gérés pour les règles métier et le cadre de la solution, mais pas pour l'interface utilisateur, les rapports ou les flux de travail. Évidemment, cela dépendra des particularités de votre projet.

Answer 4

Soit dit en passant, TestDriven.Net est un excellent frontal pour le complément VisualStudio de NUnit. , gratuit pour utilisation open source / étudiants.