Problèmes avec l'attribut DeploymentItem
Je gère actuellement un "ancien" système écrit en C # .net, en supprimant certaines fonctionnalités obsolètes et en procédant à une refactorisation. Merci mon Dieu, le gars précédent a écrit des tests unitaires (MSTests). Je suis assez à l'aise avec les tests JUnit, mais je ne fais pas encore grand chose avec MSTests.
Les méthodes de test ont un attribut DeploymentItem, spécifiant un fichier texte qui est analysé par la méthode de logique applicative en cours de test, et une 2ème DeploymentItem où seul un chemin a été spécifié, contenant un ensemble de fichiers TIF devant également être déployés.
[TestMethod()]
[DeploymentItem(@"files\valid\valid_entries.txt")]
[DeploymentItem(@"files\tif\")]
public void ExistsTifTest()
{
...
}
Les tests fonctionnaient auparavant, mais je devais maintenant changer les noms des fichiers TIF contenus dans le répertoire\files\tif. Selon une règle, les noms de fichiers TIF doivent correspondre à un certain modèle qui est également vérifié par la méthode ExistsTifTest() . Maintenant, je devais changer les noms de fichiers afin de les adapter aux nouvelles exigences et soudainement, les fichiers TIF ne sont plus. être déployé comme avant.
Quelqu'un peut-il me dire pourquoi cela se produit ou quelle peut en être la cause? La même chose se produit également si j'ajoute un nouveau fichier texte, par exemple "my2ndTest.txt" à côté de "valid_entries.txt" dans le répertoire\files\valid\avec l'attribut DeploymentItem correspondant sur la méthode de test. Le fichier n'est pas déployé?
J'ai obtenu les images déployées en définissant le chemin de déploiement directement dans testrunconfig, mais j'aimerais comprendre pourquoi cela se produit ou pourquoi, par exemple, mon nouveau fichier "my2ndTest.txt" n'est pas déployé, contrairement aux autres.
DeploymentItem est un peu le bordel.
Chaque fichier de votre solution aura un paramètre "Copier dans le dossier de sortie" dans VS.NET. Il faut que ce soit "Copier toujours" (ou similaire) pour que les fichiers soient dans le dossier de sortie.
Vérifiez que vous avez cet ensemble pour les nouveaux fichiers. Si vous ne disposez pas de cet ensemble, les fichiers ne seront pas copiés dans le dossier de sortie et ne pourront pas être déployés à partir du dossier de sortie dans le dossier où MSTest le fait.
Personnellement, si j'ai des fichiers dont j'ai besoin pour mes tests unitaires, j'ai constaté que leur incorporation en tant que ressources dans une assemblée et que cette assemblée se "décompresse" pendant les tests est une manière plus prévisible de faire les choses. YMMV.
note: Ces commentaires sont basés sur mon expérience avec VS2010. Les commentaires sur ma réponse suggèrent que ce n'est pas un problème avec VS2012. Je maintiens toujours que l'utilisation de ressources intégrées implique moins de "magie" et, pour moi, rend l'étape "arranger" de mes tests unitaires beaucoup plus explicite.
Dans VS2010, l'option "Activer le déploiement" était cochée dans mes Local.testsettings et l'attribut DeploymentItem ne fonctionnait pas. Je l'ai vérifié et tout a bien fonctionné ..__ J'espère que cela aide!
J'ai également rencontré des problèmes similaires, mais j'ai trouvé une solution simple en 3 étapes:
En supposant que votre structure de dossier ressemble à ceci:
SolutionFolder\
TestProjectFolder\
SubFolder\
- Allez à "Solutions Items/Local.testsettings"> "Déploiement"> Cochez "Activer le déploiement"
- Si vous utilisez VS2010, assurez-vous que la propriété "Copier dans le dossier de sortie" des fichiers que vous souhaitez déployer est définie sur "Copier toujours" ou "Copier si plus récent".
- Attribuez à votre méthode de test l'une des méthodes suivantes:
[DeploymentItem(@"TestProjectFolder\SubFolder")]pour déployer tout le contenu de<SubFolder>dans le répertoire Test Run[DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")]pour déployer tout le contenu de<SubFolder>en<TargetFolder>dans le répertoire Test Run
Une dernière note sur MSTest (au moins pour VS2010):
Si vous voulez que le <TargetFolder> porte le même nom que le <SubFolder>, l'utilisation de [DeploymentItem(@"SubFolder", @"SubFolder")] échouera de manière silencieuse, car le coureur de MSTest rencontre un cas idiot. C’est pourquoi vous devriez préfixer le <SubFolder> avec le <TestProjectFolder> comme suit: [DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]
J'espère que j'ai essayé toutes les suggestions ici et que encore mon élément de déploiement n'a pas été copié.
Ce que je devais faire ( comme suggéré ici ) était d'ajouter un deuxième paramètre à l'attribut DeploymentItem:
[DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")]
Si vous allez dans votre fichier .testrunconfig et que sous l'option de déploiement, décochez "Enable Deployment", les tests seront exécutés à leur emplacement normal et tout fonctionnera comme si l'application était exécutée en dehors d'un test unitaire.
Cela ne concerne probablement pas votre problème exact, mais voici quelques conseils que j'ai trouvés avec l'attribut [DeploymentItem].
- Copier dans le répertoire de sortie doit être défini sur Copier toujours.
Cela ne marche pasPASlorsqu'il est utilisé avec l'attribut [TestInitialize]
[TestInitialize]
[DeploymentItem("test.xlsx")]
public void Setup()
{
Il devrait être sur votre [TestMethod], par exemple.
[TestInitialize]
public void Setup()
{
string spreadsheet = Path.GetFullPath("test.xlsx");
Assert.IsTrue(File.Exists(spreadsheet));
...
}
[TestMethod]
[DeploymentItem("test.xlsx")]
public void ExcelQuestionParser_Reads_XmlElements()
{
...
}
Après avoir essayé toutes les autres suggestions énumérées ici, je ne pouvais toujours pas comprendre ce qui se passait. Enfin, j’ai découvert qu’aucun fichier de paramètres n’était sélectionné dans le menu Test/Paramètres de test, ce qui signifiait que le déploiement n’était pas activé. J'ai cliqué sur l'élément de menu Test/Paramètres de test/Sélectionner le fichier de paramètres de test, sélectionné le fichier Local.TestSettings, puis tout a fonctionné.
Je ne sais pas si cela répond exactement à la question, mais cela peut aider certains. Tout d’abord, j’ai trouvé que la case "Activer le déploiement" doit être cochée pour que le déploiement fonctionne ... Deuxièmement, le document dit que le chemin source est "par rapport au chemin du projet", ce dossier de projet. En fait, il semble faire référence au dossier de sortie de la génération . Donc, si j'ai un dossier de projet appelé 'TestFiles' et un fichier appelé Testdata.xml, utiliser l'attribut de cette façon ne fonctionne pas:
[DeploymentItem(@"TestFiles\Testdata.xml")]
Je peux marquer le fichier Testdata.xmlCopy Always, de sorte que la construction en place une copie dans le dossier de sortie (par exemple, Debug\TestFiles\TestData.xml). Le mécanisme de déploiement trouvera ensuite la copie du fichier située dans ce chemin (TestFiles\Testdata.xml) par rapport à la sortie de la génération ..__ ou je peux définir l'attribut comme suit:
[DeploymentItem(@"..\\..\TestFiles\Testdata.xml")]
et le mécanisme de déploiement trouvera le fichier d'origine . Donc, soit ça marche, mais j'ai remarqué qu'en utilisant le Copy Always je rencontre parfois le même problème que lorsque je modifie le fichier app.config dans un projet changer de code ou forcer une reconstruction, rien ne déclenche la copie des fichiers marqués pour être copiés lors de la construction.
J'avais le drapeau de déploiement désactivé en premier. Mais même après l’avoir activé, pour des raisons inconnues, même les DLLs cibles ne seraient toujours pas copiées. J'ai accidentellement ouvert la fenêtre Test Run et tué toutes les exécutions précédentes. Comme par magie, j'ai trouvé toutes les DLL et tous les fichiers dont j'avais besoin dans le dossier de test lors de la prochaine exécution ... Très déroutant.
J'avais de gros problèmes pour essayer de déployer des fichiers - pour essayer toutes les suggestions ci-dessus.
Puis j'ai fermé le VS2010; il a redémarré, chargé la solution et tout a fonctionné. (!)
J'ai fait des vérifications; Après avoir défini l'indicateur "Activer le déploiement" sur local.TestSetting, vous ne devez pas simplement réexécuter le test à partir de la fenêtre Résultats du test. Vous devez supprimer le test précédent de l'interface utilisateur, par exemple. en effectuant un test différent ou en rouvrant votre solution.
J'ai travaillé sur cela dans VS2013. Mes découvertes pour que cela fonctionne:
- Copier dans le répertoire de sortie doit être défini sur Copier toujours: OBLIGATOIRE.
- "Activer le déploiement" dans .TestSettings: NON REQUIS. Je travaille ce Sans un fichier .TestSettings du tout.
- Spécification d’un dossier en tant que 2e paramètre: FACULTATIF. Forme la disposition du dossier de sortie, fonctionne bien sans.
- SPACES dans le nom du fichier: cela m'a causé un mal de tête - le fichier n'a jamais été copié. Supprimer les espaces a résolu ce problème. Je n'ai pas encore examiné les personnages d'évasion.
Un conseil que j’ai appris à la dure: n’oubliez pas d’ajouter cet attribut à chaque test. Le fichier est copié lors du premier test attribué dans la série de tests, mais est resté manquant lorsque l'ordre des tests a été modifié et que des tests non attribués ont tenté de trouver le fichier en premier.
Comme j'ai toujours trouvé l'attribut DeploymentItem comme un gâchis, je réalise le déploiement de tels fichiers à l'aide du script de post-génération .- Assurez-vous que les fichiers que vous souhaitez copier possèdent la propriété Copier toujours définie .- Modifier votre test projet de script de post-génération pour copier les fichiers du dossier cible de la génération (Bin\Debug) vers l’emplacement où votre test les attend.
Nous avons passé beaucoup de temps par problème d’éléments de déploiement à le résoudre dans la course unittest locale et la réunion par équipe unitaire également. Ce n'est pas facile.
Très bon outil pour déboguer ce problème est ProcessExplorer . À l'aide de Process Explorer, vous pouvez vérifier où Visual Studio recherche les éléments de déploiement et apporter la correction au projet. Il suffit de filtrer toutes les opérations de fichier où chemin contient votre nom de fichier de déploiement et vous le verrez.
Pour ceux qui préfèrent éviter le fouillis de DeploymentItem et adopter l'approche proposée par @Martin Peck (réponse acceptée), vous pouvez utiliser le code suivant pour accéder au contenu de la ressource incorporée:
public string GetEmbeddedResource(string fullyQulifiedResourceName)
{
var Assembly = Assembly.GetExecutingAssembly();
// NOTE resourceName is of the format "Namespace.Class.File.extension";
using (Stream stream = Assembly.GetManifestResourceStream(fullyQulifiedResourceName))
using (StreamReader reader = new StreamReader(stream))
{
string result = reader.ReadToEnd();
}
}
Pour plus de détails, voir this SO Thread
Outre l'attribut de déploiement devant être vérifié, j'ai découvert autre chose à propos de l'attribut DeploymentItem.
[TestMethod()]
[DeploymentItem("folder\subfolder\deploymentFile.txt")]
public void TestMethod1()
{
...
}
Votre fichier deploymentFile.txt doit être relatif au fichier de solution et non au fichier testfile.cs.
Pour moi, la cause fondamentale était entièrement différente: le code de production utilisé par mes tests consistait à renommer et/ou à supprimer le fichier de test .xml en cours de déploiement.
Par conséquent, lorsque j'exécutais mes tests individuellement, ils passaient, mais en les exécutant tous ensemble, le deuxième test et les suivants échouaient avec des erreurs "fichier non trouvé" (que j'avais à l'origine mal diagnostiquées comme l'attribut DeploymentItem ne fonctionnant pas) .
Ma solution consistait à demander à chaque méthode de test de créer une copie du fichier déployé (à l'aide de cette technique ), puis de faire en sorte que le code de production testé utilise le fichier copié au lieu de l'original.
Essayez ceci pour VS2010. Donc, vous n'avez pas besoin d'ajouter DeployItems pour chaque tif
Retirer le
[DeploymentItem(@"files\valid\valid_entries.txt")]
[DeploymentItem(@"files\tif\")]
Ajouter une configuration de test.
- clic droit sur le noeud de la solution dans l'explorateur de solutions
- Ajouter -> Nouvel élément ...
- Sélectionnez le noeud Paramètres de test à gauche, sélectionnez l'élément à droite.
- Cliquez sur Ajouter
Appelez-le par exemple TDD
Choisissez TDD sous TestMenu> Edit Testsettings.
Cliquez sur le déploiement. Activez-le, puis ajoutez les fichiers et les répertoires souhaités. Un chemin d'accès sera associé à la solution. Les fichiers seront mis sur. Les fichiers originaux sont par exemple ici:
D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml
Lorsque je lance mon test unitaire, il est copié dans
D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Patrik_HERKULES 2011-12-17 18_03_27\Authority.xml
dans testcode je l'appelle de:
[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()
{
string authorityFile = "Authority.xml";
var Xmldoc = XDocument.Load(authorityFile);
Il n’est pas nécessaire de choisir Copier toujours; mettre les fichiers dans le testproject; ajouter des chemins codés en dur dans le code de test. Pour moi, cette solution a fonctionné mieux. J'ai essayé avec DeploymentItem, copie toujours mais ce n'était pas à mon goût.
J'ai également rencontré des problèmes similaires. J'ai toutes les étapes mentionnées ci-dessus mais toujours pas de chance. J'utilise VS2010. Ensuite, j'ai découvert que $ Menu> Test> Sélectionner le paramètre de test actif> Tracer et tester l’impact a été sélectionné. Il a commencé à fonctionner après avoir modifié la trace et testé l'impact sur Local . Cette page contient des informations très utiles sur la copie de fichiers dans le dossier de résultats des tests, ce qui me permet d’ajouter cette expérience.
N'utilisez pas DeploymentItem.
Il est très difficile de configurer correctement et cela ne fonctionnait pas avec mon testeur ReSharper ni avec le programme natif de MSTEST dans Visual Studio 2017.
Au lieu de cela, cliquez avec le bouton droit sur votre fichier de données et sélectionnez properties . Sélectionnez Copier dans le répertoire de sortie: Toujours .
Maintenant, dans votre test, faites ceci. Le répertoire est simplement le répertoire du fichier relatif au projet de test. Facile.
[TestMethod()]
public void ParseProductsTest()
{
// Arrange
var file = @"Features\Products\Files\Workbook_2017.xlsx";
var fileStream = File.Open(file, FileMode.Open);
// etc.
}
Caveat. Je ne sais pas si cela fonctionne bien avec les systèmes de construction et de test automatisés. Je ne suis pas encore là.
Mon gros "gotcha" était la façon dont DeploymentItem gère les annuaires. J'utilisais la version à deux paramètres avec les deux comme chemin de répertoire contenant les sous-répertoires que je voulais déployer. Au début, je n'avais pas réalisé que cela ne faisait que copier le contenu de la racine du répertoire et non la totalité de la structure de dossiers récursive!
J'avais fondamentalement [DeploymentItem (@ "Foo \", @ "Foo \")] et je m'attendais à ce qu'il déploie mon Foo\Bar. Je devais spécifiquement le changer en [DeploymentItem (@ "Foo\Bar \", @ "Foo\Bar \")] et cela fonctionne maintenant comme un charme.