Dans .NET, devez-vous placer des projets de test unitaires avec le reste de la solution? Ou devrait-il y avoir une solution de test qui abrite tous les projets de test?Tests de projets en solution
Nous avons tous les projets de test avec notre solution de base de code ... il semble un peu lourd.
Que faites-vous habituellement?
Dans notre projet actuel, nous avons décidé de mettre tous les tests unitaires dans des projets distincts. Le code et les tests de l'application sont dans la même solution, mais au moins nous pouvons construire (et déployer) une version sans le code de test unitaire. L'inconvénient de ceci - jusqu'à présent - est que parfois vos tests unitaires ne peuvent pas atteindre certains membres du code de l'application (protégés et internes), mais cela nous amène généralement à découvrir que notre conception pourrait être améliorée.
Et je suppose que je devrais souligner un fil similaire Here avec plus de réponses sur le même sujet/similaire.
Je les ai toujours gardés comme partie de la solution - après tout, ils font partie de la solution. Vous pouvez cependant avoir plusieurs solutions pour différentes approches de visualisation de vos projets, donc une solution sans test peut être ce que vous voudriez créer dans certains cas.
Je n'utilise pas .NET, mais lorsque je développe des cas de test, je les garde isolés du reste du code pour que je puisse déployer l'application sans les tests. L'utilisateur n'a pas besoin, ou même envie de ce genre de choses.
Étant donné que vous n'utilisez pas .NET, vous ne comprenez apparemment pas le concept d'une "solution". Mettre des projets d'application et tester des projets dans les mêmes solutions ne signifie PAS que les tests sont inclus dans le produit que vous fournissez réellement aux utilisateurs finaux. – raven
Notre code de test n'est pas livré mais fait partie de la solution dans son ensemble. Notre constructeur sépare les assemblages de test et les composants de base. Du point de vue de la gestion de solutions, il semble qu'une solution avec plus de 140 projets soit écrasante.
Nous sommes passés par là et, à un moment donné, nous avons divisé ce qui était une solution unique avec plus de 60 projets en 2 ou 3 solutions. Les projets de test sont toujours dans la même solution que le code de l'application qu'ils testent. – FOR
Cela me semble être une solution solide. –
Nous utilisons toujours un projet distinct dans la même solution. Cela signifie que nous pouvons être certains (en utilisant des références) que le code de test unitaire teste également nos références explicites (plutôt que de prendre implicitement une certaine visibilité de quelque chose parce qu'il est dans le même assemblage - par exemple "Interne")
Regardez la conception de votre projet. Si elle est proche de la disposition MVC ou de l'une de ses alternatives, vous devriez avoir des niveaux distincts d'assemblages différents. Faire un sous-ensemble de test pour chaque niveau de votre conception.
Notre projet de test s'exécute généralement à la place du projet qui crée le fichier EXE. Notre projet EXE est un shell fin qui transmet un événement et des informations à un assembly rempli de classes de contrôleurs contenant le code que la plupart des personnes placent dans un projet EXE. Cela permet au projet de test de prétendre être le fichier EXE pour 90% du processus de test normal.
Nous sommes encore en train d'élaborer la meilleure solution pour les cas de test réels. À l'heure actuelle, nous avons plusieurs niveaux principaux de notre utilitaire de cadre, objets Applicaiton, cadre de l'interface utilisateur, les commandes, les contrôleurs d'interface utilisateur et EXE. Nous avons un assembly pour chaque niveau sauf EXE (qui est testé manuellement). Lorsque nous modifions un assemblage, nous chargeons l'ensemble de test pour ce niveau. Lorsque nous devons faire quelque chose qui touche tous les niveaux, nous devons charger tous les assemblages de test.
Lors de notre processus de construction d'un seul bouton, nous exécutons le projet de test exe. (Nous avons un utilitaire séparé pour cela).
En règle générale, je mets des tests unitaires dans leur propre projet et des tests d'intégration dans leur propre projet au sein de la solution de l'application.Là où je travaille, nous envisageons de mettre les tests Web dans une solution distincte. Nous prévoyons de partager la création de tests Web avec l'équipe de contrôle qualité et nous ne souhaitons pas que ces tests deviennent une responsabilité de build.
Essayez InternalsVisibleToAttribute (assemblage des cibles), vos tests unitaires peuvent accéder aux membres internes. Privé nécessite hackarounds en utilisant la réflexion, donc je les marque toujours internes si elles nécessitent des tests indépendants. – cfeduke
(Et je pense que le PO fait déjà ce que vous avez suggéré, il se demande si la solution devrait avoir plusieurs projets de test ou s'il devrait y avoir une solution séparée qui contient juste des projets de test.) – cfeduke
cfeduke: merci de m'indiquer InternalsVisibleToAttribute! – FOR