Organisation des tests unitaires dans Visual Studio

Question

Je suis en train de créer un ensemble de test unitaire apparié pour chaque assemblage de mon projet, les deux étant dans le même dossier.

• MyProject/MyProject.csproj
• MyProject.Test/MyProject.Test.csproj

Regarder des projets open source, j'ai vu un certain petit projet mis tous les tests dans un ensemble, et D'autres l'ont divisé comme le mien. J'ai affaire à une solution de grande taille, il serait donc fou de mettre tous les tests dans un projet.

J'ai actuellement la logique msbuild pour exécuter des tests sur tous les fichiers * .Test.csproj. Si j'avais tous mes tests dans un dossier différent, je n'aurais pas besoin de faire ça.

Je me demandais simplement s'il y avait de bons arguments pour faire les choses d'une certaine façon.

Merci

Answer 1

je le fais même façon mais Je change l'espace de nom par défaut fo r chaque projet de test doit correspondre à l'espace de nom du projet de production. Ainsi, les tests pour la classe X.Y.Foo sont en X.Y.FooTest plutôt qu'en X.Y.Test.FooTest - cela signifie que vous avez besoin de moins de directives d'utilisation et que cela simplifie généralement les choses. La raison principale pour laquelle je souhaite conserver les deux dans des projets séparés est d'éviter d'inclure les tests dans la bibliothèque de production ou d'expédier une bibliothèque non testée. Avec la structure de projet séparée, vous pouvez exécuter des tests unitaires sur tout ce que vous construisez. Il est également plus facile de regarder à travers les classes de production sans avoir deux fois plus de fichiers à regarder (en obtenant la "sensation" d'une bibliothèque). Enfin, n'oubliez pas que si vous devez accéder aux membres internal lors des tests, il y a toujours [InternalsVisibleTo].

Answer 2

je fais la même chose, sauf que chaque projet est dans son propre dossier sous le même dossier racine. Quelque chose le long de ce qui suit:

Solution Dossier

• ProjectA dossier
• ProjectA.Test dossier
• ProjectB dossier
• dossier ProjectB.Test

Answer 3

J'ai toujours un projet de test séparé pour chaque projet. Une partie de cela est simplement que j'aime son organisation, mais j'ai aussi souvent rencontré des situations où j'ai décidé de transformer une bibliothèque en sa propre solution pour qu'elle puisse être réutilisée par d'autres solutions. Dans ces cas, si le projet de bibliothèque possède son propre projet de test (plutôt que tous les tests d'un seul projet), il est beaucoup plus facile de sortir cette bibliothèque.

Answer 4

Je suggère de faire le moins de projets de tests unitaires possible. La raison en est que chacun que vous créez ajoute au moins dix secondes de temps de compilation. Dans un grand projet, il commence à additionner.

est ici la structure du répertoire que j'utilise:

projectName/branches/trunk/projets/code/codeproject1
projectName/branches/trunk/projets/code/codeproject2
projectName/branches/trunk/projets/code/codeproject3
PROJECTNAME/branches/trunk/projets/Tests/TestProject1
PROJECTNAME/branches/trunk/ dépendances/PROJECTNAME prototypes
PROJECTNAME/...

et dans TestProject1, la structure de répertoire suivant:

codeproject1/
codeproject2/
codeproject2/web
codeproject2/web/mvc
codeproject3/
codeproject3/support