J'essaie de réintroduire des tests unitaires dans mon équipe car notre couverture actuelle est très mauvaise.
Notre système est assez important de plus de 40 projets / assemblys. Nous utilisons actuellement un projet nommé [SystemName] .Test.CsProj Était tout le code de test est déversé et organisé pour représenter les espaces de noms à l'aide de dossiers. Cette approche n'est pas très évolutive et rend difficile la recherche de tests.
J'ai pensé à ajouter un dossier tests à chaque projet, cela mettrait les tests d'unité "dans les développeurs face" et les rendre faciles à trouver. L'inconvénient est que le code de libération de la production contiendrait des références à Nunit, Nmocks ainsi que le code de test et les données de test ... Quelqu'un a-t-il essayé cette approche?
Comment tout le monde travaille-t-il avec des tests unitaires sur de grands projets? Avoir un projet de tests par "réel" projet / assembly présenterait trop de nouveaux projets.
Merci d'avance
3 Réponses :
J'utilise personnellement l'approche en projet. Étant donné qu'un seul projet est un module logiciel sur ses propres (et peut donc être expédié ou utilisé dans d'autres projets), je pense que la meilleure approche consiste à attacher les tests sur le module logiciel unique. Il suit automatiquement le code testé. < / p>
Je pense que c'est une mauvaise idée pour les raisons que vous avez énoncées, vous avez fini par avoir des références dans le code de production pour tester des assemblages, ainsi que tous vos tests sont compilés dans votre code de production, à moins que vous ne fassiez de la magie pour exclure. ça.
Vous ne dites pas pourquoi les tests sont difficiles à trouver. S'ils reflètent la structure des choses dont ils testeront, ils ne devraient pas être plus difficiles à trouver que le code qu'ils testent.
Vous devriez avoir un serveur CI qui exécute tous les tests tout le temps, de sorte que même si les tests ne sont pas dans la face Devs, ils ne peuvent pas passer la place du fait qu'ils ont cassé la construction facilement.
Nous avons tendance à utiliser les tests dans leur propre projet, mais que ce projet est dans un test (ou tests.Integration ou Wahatever Les tests sont pour) le sous-dossier de l'Assemblée qu'ils testent. De cette façon, les tests sont obtenus lorsque le code du projet est vérifié et que vous n'avez pas les dossiers de projets de test polluant la structure de répertoire au niveau du projet. Mais vous vous retrouvez avec au moins 1 projet de test pour chaque assemblée que vous avez. Je pense que c'est correct, sauf si vous avez de nombreux petits assemblages, mais dans ce cas, avez-vous vraiment besoin d'avoir le code pour tous dans l'IDE tout le temps, ou pourriez-vous simplement avoir le code des assemblages que vous travaillez sur localement et avoir les autres assemblages viennent de référencer par la DLL?
J'ai travaillé sur un grand projet (5 millions de lignes de code, ~ 160 000 tests d'unité) qui utilisaient la classe de test au bas de chaque fichier, dans un espace de noms séparé, enveloppé dans un débogage #.
Les références à Nunit existaient dans la production, mais le code de test n'a pas été inclus dans la version de déverrouillage, de sorte que cela ne rendait pas la production de production plus grande.
La prestation était que le code de test était là avec le code de production, de sorte qu'il n'a jamais été difficile de trouver les tests. Il était également clair que les tests appartenaient à quelles classes, et il n'était pas nécessaire d'essayer d'imiter une hiérarchie des espaces de noms dans un dossier tests, qui est toujours un problème si les espaces de noms ou les noms de classe changent.
Cela a fonctionné assez avec succès pour le projet, mais les opinions et le kilométrage peuvent varier de nos jours :) L'endroit où je travaille actuellement pour une structure est très similaire au titulaire de Sam décrit.