12
votes

Comment obtenir un test d'unité pour copier mes DLL et d'autres fichiers lorsque je passe un test?

Je travaille sur une application et j'ai créé un certain nombre de tests unitaires pour cela. Le projet avec la classe de test dépend de 3 DLL tiers. Lorsque je vais au dossier BIN \ DEBUG pour le projet de test, les DLL sont là. Mais lorsque j'exécute le test, les DLL ne sont pas copiés dans le dossier TestResult \\ Out.

Il existe également un fichier log4net.config d'un autre projet que j'aimerais avoir copié. Celui-ci ne s'affiche pas dans le dossier Bin \ Bin \ Débug de test, c'est donc un autre problème que je dois résoudre.

Comment puis-je obtenir ces fichiers à copier lorsque j'exécute le test de l'unité?

Tony


3 commentaires

De quoi vous testez-vous? Nunit? Mstest?


Mstest, je pense. L'outil situé dans Visual Studio 2010.


Poste associé - Comment puis-je obtenir "Copier au répertoire de sortie" pour fonctionner avec des tests d'unité?


5 Réponses :


5
votes

Nous avons un dossier bin contenant des dll tiers qui doivent faire partie des constructions. Ils sont marqués avec l'attribut «Copier local» dans la référence.

Quant aux fichiers individuels, vous pouvez faire la même chose - Définir «Copier sur le répertoire de sortie» sur True.


1 commentaires

Merci! Qui corrigé les DLL. Je ne comprends pas bien comment résoudre le problème avec le fichier log4net.config. Celui-ci est dans un autre projet et a-t-il de "copier dans le répertoire de sortie" de propriété définie sur "Copier si plus récent" (j'utilise VS 2010). Mais il n'est pas copié dans le dossier Bin \ Bin \ Débug de test, et le test dépend de ce projet.



0
votes

une telle copie de la DLL (en dehors de les référencer - où vous pouvez dire copier local ) et les mettre dans le dossier OUT ne doit pas faire partie de vos tests, mais une partie de votre processus de construction / d'emballage. Avoir des scripts de construction qui font la copie nécessaire des DLL.


1 commentaires

Les DLL sont référencées mais ils n'étaient pas copiés. C'est parce que la copie locale de ces DLL était fausse. Ils ne font pas partie du processus de test, sauf qu'ils sont utilisés par le code.



12
votes

Vous pouvez utiliser un déploiementItemattribute pour copier des fichiers dans le répertoire BIN (ou autre).

[TestMethod()]
[DeploymentItem("log4net.config")]
public void SomeTest()
{
   ...
}


1 commentaires

Je vais essayer d'essayer quand je retourne au travail le matin. Cela semble prometteur!



0
votes

Lorsque vous avez débogué à partir de Studio, utilisez l'attribut de déploiement sur la classe ou le testMethod pour copier les fichiers DLL et les fichiers de configuration requis dans le dossier Out où les MSTST sont exécutés. Si vous exécutez à partir de la ligne de commande, utilisez un fichier de testSettings et désactivez l'option de déploiement et définissez votre dossier BIN comme répertoire de travail. Utilisez / renvoyez ce fichier Testsettings dans votre ligne de commande pour exécuter Mstest. De cette façon, vous pouvez exécuter Mstest directement dans votre dossier BIN sans dévisser les DLL dans un répertoire OUT. Encore une fois, utilisez l'attribut de déploiement à déboguer de Studio, les testsettings ne fonctionneront pas.


0 commentaires

3
votes

J'ai trouvé si vos tests sont déployés dans la zone de test (true par défaut), la copie locale ne fonctionnera pas dans certaines circonstances telles que le chargement de l'assemblage dynamique.

Vous pouvez soit transformer ce déploiement en utilisant un Fichier RunSettings ( https://msdn.microsoft.com/en-us/library/ MS182475.aspx ) et P>

[DeploymentItem("bin\\release\\iRock.dll")]
[DeploymentItem("bin\\debug\\iRock.dll")]


0 commentaires