Projets de tests en solution

Question

Dans .NET, devez-vous placer des projets de test unitaire avec le reste de la solution? Ou devrait-il y avoir une solution de test qui héberge tous les projets de test?

Nous avons tous les projets de test dans notre solution de base de code ... cela semble un peu lourd.

Que faites-vous habituellement?

Answer 1

Dans notre projet actuel, nous avons décidé de regrouper tous les tests unitaires dans des projets distincts. Le code de l'application et les tests font partie de la même solution, mais nous pouvons au moins construire (et déployer) une version sans le code de test unitaire.

L'inconvénient de ceci - jusqu'à présent - a été 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 signaler un fil similaire Ici avec plus de réponses sur le même sujet / un sujet similaire.

Answer 2

Je les ai toujours gardés dans la solution - ils font, après tout, partie de la solution. Vous pouvez avoir plusieurs solutions pour différentes approches d'affichage de vos projets. Une solution sans test peut donc être ce que vous voudriez créer dans certains cas.

Answer 3

Notre code de test n'est pas envoyé, mais ils font partie de la solution dans son ensemble. Notre constructeur sépare les assemblages de test et les composants principaux. Du point de vue de la gestion de la solution, il semble qu’une solution comportant plus de 140 projets est écrasante.

Answer 4

Nous utilisons toujours un projet distinct dans la même solution.

Cela signifie que nous pouvons être certains (à l'aide de références) que le code de test unitaire teste également nos références explicites (au lieu de prendre implicitement une partie de la visibilité de quelque chose car il se trouve dans le même assemblage - par exemple, "Interne").

Answer 5

En général, je place des tests unitaires dans leur propre projet et des tests d'intégration dans leur propre projet au sein de la solution d'application.

Là où je travaille, nous envisageons de placer les tests Web dans une solution distincte. Nous prévoyons de partager la création de tests Web avec l'équipe d'assurance qualité et nous ne voulons pas que ces tests deviennent un passif de développement.

Answer 6

Je n'utilise pas .NET, mais lorsque je développe des scénarios de test, je les garde isolés du reste du code afin de pouvoir déployer l'application sans les tests. L'utilisateur n'a pas besoin de, ni même envie de ce genre de choses.

Answer 7

Regardez la conception de votre projet. S'il se trouve à proximité de la structure MVC ou de l'une de ses alternatives, vous devez avoir des niveaux distincts d'assemblages différents. Créez 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 mince qui transmet les événements et les informations à un assemblage contenant des classes de contrôleurs contenant le code que la plupart des utilisateurs ont inséré 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 travaillons toujours sur le meilleur arrangement pour les cas de test réels. Nous disposons actuellement de plusieurs niveaux majeurs dans notre utilitaire d'infrastructure, les objets Applicaiton, l'infrastructure d'interface utilisateur, les commandes, les contrôleurs d'interface utilisateur et le fichier EXE. Nous avons un assemblage pour chaque niveau sauf pour EXE (qui est testé manuellement). Lorsque nous modifions un assemblage, nous le chargeons pour ce niveau. Lorsque nous devons faire quelque chose qui touche tous les niveaux, nous devons charger tous les assemblages de test.

Au cours de notre processus de création à un bouton, nous exécutons le projet test exe. (Nous avons un utilitaire séparé pour cela).