Problèmes avec l’atsortingbut DeploymentItem

Je maintiens actuellement un “vieux” système écrit en C # .net, en supprimant certaines fonctionnalités obsolètes et en procédant à des refactoring. 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 n’ai pas encore beaucoup fait avec les MSTests.

Les méthodes de test ont un atsortingbut DeploymentItem , spécifiant un fichier texte qui est analysé par la méthode de logique métier en cours de test et un 2nd DeploymentItem où seul un chemin contenant un groupe de fichiers TIF doit être déployé.

 [TestMethod()] [DeploymentItem(@"files\valid\valid_ensortinges.txt")] [DeploymentItem(@"files\tif\")] public void ExistsTifTest() { ... } 

Les tests fonctionnaient auparavant, mais maintenant je devais changer le nom 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 pour les adapter aux nouvelles exigences et les fichiers TIF ne sont plus déployés comme avant.

Est-ce que quelqu’un peut me donner un indice 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 “my2ndTest.txt” à côté de “valid_ensortinges.txt” dans le répertoire \ files \ valid \ avec l’atsortingbut DeploymentItem correspondant sur la méthode de test. Le fichier n’est pas déployé?

J’ai maintenant les images déployées en définissant le chemin de déploiement directement dans testrunconfig, mais je voudrais comprendre pourquoi ces choses se produisent ou pourquoi, par exemple, mon nouveau fichier “my2ndTest.txt” n’est pas déployé pendant que les autres le font.

DeploymentItem est un peu un désordre.

Chaque fichier de votre solution aura un paramètre “Copy To Output Folder” dans VS.NET. Vous avez besoin de ceci pour être “Copy Always” (ou similaire) afin d’obtenir les fichiers dans le dossier de sortie.

Vérifiez que vous avez cet ensemble pour les nouveaux fichiers. Si vous ne possédez pas cet ensemble, les fichiers ne seront pas copiés dans le dossier de sortie, et ils 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 trouvé que l’incorporation de ces fichiers dans un assemblage et que cet assemblage se décompressait pendant les tests était une façon plus prévisible de faire les choses. YMMV.

note: Ces commentaires sont basés sur mon expérience avec VS2010. Les commentaires à ma réponse suggèrent que ce n’est pas un problème avec VS2012. Je persiste à dire que l’utilisation de ressources intégrées implique moins de «magie» et, pour moi, rend l’étape «d’arrangement» de mes tests unitaires beaucoup plus explicite.

Dans VS2010, mes “Local.testsettings” avaient le “Enable Deployment” désactivé et l’atsortingbut DeploymentItem ne fonctionnait pas. Je l’ai vérifié et tout s’est bien passé. J’espère que ça aide!

J’ai également rencontré des problèmes similaires, mais j’ai trouvé une solution simple en 3 étapes pour cela:

En supposant que votre structure de dossiers ressemble à ceci: SolutionFolder\ TestProjectFolder\ SubFolder\

  1. Accédez à “Solutions Items / Local.testsettings”> “Déploiement”> Cochez “Activer le déploiement”
  2. Si vous utilisez VS2010, assurez-vous que la propriété “Copier dans le dossier de sortie” de tous les fichiers à déployer est définie sur “Toujours copier” ou “Copier si plus récent”.
  3. Atsortingbuez votre TestMethod avec l’un des:
    • [DeploymentItem(@"TestProjectFolder\SubFolder")] pour déployer tout le contenu de dans le répertoire Test Run
    • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")] pour déployer tous les contenus de dans dans le répertoire Test Run

Une dernière remarque à propos de MSTest (au moins pour VS2010):

Si vous voulez que le le même nom que le , l’utilisation de [DeploymentItem(@"SubFolder", @"SubFolder")] échouera silencieusement lorsque le runner MSTest atteindra un cas d’arête idiot. C’est pourquoi vous devez préfixer le avec comme : [DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Pour, espérons-le, aider quelqu’un d’autre: j’ai essayé toutes les suggestions ici et mon élément de déploiement n’était toujours pas copié.

Ce que je devais faire ( comme suggéré ici ) était d’append un second paramètre à l’atsortingbut DeploymentItem:

 [DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")] 

Si vous allez dans votre fichier .testrunconfig et en cours de déploiement, décochez la case “Activer le déploiement”, les tests s’exécuteront à leur emplacement normal et tout fonctionnera comme lors de l’exécution de l’application en dehors d’un test unitaire.

Cela ne concerne probablement pas votre problème exact, mais voici quelques astuces que j’ai trouvées avec l’atsortingbut [DeploymentItem].

  1. Copier dans le répertoire de sortie doit être défini sur Copier toujours.

Il ne fonctionne pas lorsqu’il est utilisé avec l’atsortingbut [TestInitialize]

 [TestInitialize] [DeploymentItem("test.xlsx")] public void Setup() { 

Il devrait être sur votre [TestMethod], par exemple

  [TestInitialize] public void Setup() { ssortingng spreadsheet = Path.GetFullPath("test.xlsx"); Assert.IsTrue(File.Exists(spreadsheet)); ... } [TestMethod] [DeploymentItem("test.xlsx")] public void ExcelQuestionParser_Reads_XmlElements() { ... } 

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 indique que le chemin source est “relatif au chemin du projet”, ce que je prenais au départ pour désigner le dossier du projet. En fait, il semble faire référence au dossier de sortie de la construction. Donc, si j’ai un dossier de projet appelé ‘TestFiles’ et un fichier appelé Testdata.xml , utiliser l’atsortingbut de cette façon ne fonctionne pas:

 [DeploymentItem(@"TestFiles\Testdata.xml")] 

Je peux marquer le fichier Testdata.xml Copy Always , de sorte que la génération place une copie sous le dossier de sortie (par exemple, Debug\TestFiles\TestData.xml ). Le mécanisme de déploiement trouvera alors la copie du fichier situé sur ce chemin ( TestFiles\Testdata.xml ) par rapport à la sortie de génération. Ou, je peux définir l’atsortingbut de cette façon:

 [DeploymentItem(@"..\\..\TestFiles\Testdata.xml")] 

et le mécanisme de déploiement trouvera le fichier d’origine. Donc, soit fonctionne, mais j’ai remarqué que l’utilisation de Copy Always Je rencontre parfois le même problème que lorsque je modifie le fichier app.config dans un projet – si je ne change pas de code ou ne force pas la reconstruction, rien ne déclenche la copie de fichiers marqué pour être copié lors de la construction.

Après avoir essayé toutes les autres suggestions listées ici, je n’arrivais toujours pas à comprendre ce qui se passait. Enfin, j’ai découvert qu’aucun fichier de parameters n’était sélectionné dans le menu Paramètres de test / test, ce qui signifiait que le déploiement n’était pas activé. J’ai cliqué sur l’élément de menu Test / Test Settings / Select Test Settings File, sélectionné le fichier Local.TestSettings, puis tout a fonctionné.

Le drapeau de déploiement a été désactivé en premier. Mais même après l’avoir activé, pour une raison inconnue, même les DLL cibles ne seraient toujours pas copiées. Accidentellement, j’ai ouvert la fenêtre Test Run et tué toutes les exécutions précédentes. Par magie, j’ai trouvé toutes les DLL et tous les fichiers nécessaires dans le dossier de test lors de la prochaine exécution … Très déroutant.

J’avais de gros problèmes à essayer de déployer des fichiers – en essayant toutes les suggestions ci-dessus.

Puis j’ai fermé VS2010; redémarré, chargé la solution et tout a fonctionné. (!)

J’ai fait quelques 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 exécutant un test différent ou en rouvrant votre solution.

Comme j’ai toujours trouvé que l’atsortingbut DeploymentItem était en désordre, je procède au déploiement de ces fichiers en utilisant le script post-build. – Assurez-vous que les fichiers que vous voulez copier ont le jeu de propriétés Copier toujours. – Modifiez le script de post-construction de votre projet de test pour copier les fichiers du dossier cible de la compilation (Bin \ Debug) vers l’emplacement auquel votre test les attend.

Essayez ceci pour VS2010. Vous n’avez donc pas besoin d’append DeployItems pour chaque tif
Retirer le

 [DeploymentItem(@"files\valid\valid_ensortinges.txt")] [DeploymentItem(@"files\tif\")] 

Ajouter une configuration de test.
– Cliquez avec le bouton droit sur le nœud de la solution dans l’explorateur de solutions
– Ajouter -> Nouvel élément …
– Sélectionnez le nœud 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 répertoires de votre choix. Il y aura un chemin relatif à la solution. Les fichiers seront mis Le fichier original est par exemple ici:

 D:\Users\Pasortingk\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml 

Lorsque je lance mon test unitaire, il est copié dans

 D:\Users\Pasortingk\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Pasortingk_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() { ssortingng authorityFile = "Authority.xml"; var Xmldoc = XDocument.Load(authorityFile); 

Il n’est pas nécessaire de choisir Copier Toujours; placer les fichiers dans le projet de test; Ajouter des chemins codés en dur dans le code de test. Pour moi, cette solution a fonctionné le mieux. J’ai essayé avec DeploymentItem, copie toujours mais ce n’était pas à mon goût.

J’ai travaillé sur ceci dans VS2013. Mes conclusions pour que cela fonctionne:

  • Copier dans le répertoire de sortie doit être défini sur Toujours copier: OBLIGATOIRE.
  • “Activer le déploiement” dans .TestSettings: NON REQUIS. Cela fonctionne sans fichier .TestSettings.
  • Spécifier un dossier comme 2ème paramètre: FACULTATIF. Forme la disposition du dossier de sortie, fonctionne bien sans.
  • ESPACES dans le nom de fichier: cela m’a causé un mal de tête – le fichier n’a jamais été copié. Enlever les espaces corrigé Je n’ai pas encore cherché les caractères d’échappement.

Un conseil que j’ai aussi appris à la dure: n’oubliez pas d’append cet atsortingbut à chaque test individuel. Le fichier copie lors du premier test atsortingbué dans le testrun, mais rest manquant lorsque l’ordre des tests a changé et que les tests non atsortingbués ont tenté de trouver le fichier en premier.

Pour ceux qui préfèrent éviter le désordre de DeploymentItem et adopter l’approche suggéré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 ssortingng GetEmbeddedResource(ssortingng 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)) { ssortingng result = reader.ReadToEnd(); } } 

Pour plus de détails, voir ce fil de discussion

Pour moi, la cause profonde était autre chose: le code de production utilisé par mes tests était de renommer et / ou de supprimer le fichier de test .xml en cours de déploiement.

Par conséquent, lorsque j’exécutais mes tests individuellement, ils réussissaient, mais lorsqu’ils étaient tous exécutés ensemble, le deuxième et les tests suivants échoueraient avec des erreurs “fichier introuvable” (que j’avais initialement mal diagnostiqué car l’atsortingbut DeploymentItem ne fonctionnait pas) .

Ma solution consistait à faire en sorte que chaque méthode de test crée une copie du fichier déployé (à l’aide de cette technique ), puis que le code de production en cours de test utilise le fichier copié au lieu de l’original.

Mon grand “gotcha” était la façon dont DeploymentItem gère les répertoires. J’utilisais la version à deux parameters avec les deux comme répertoire contenant des sous-répertoires que je souhaitais déployer. Au début, je n’avais pas réalisé que cela ne copiait que le contenu de la racine du répertoire et non la structure de dossier récursive en entier!

J’avais essentiellement [DeploymentItem (@ “Foo \”, @ “Foo \”)] et je m’attendais à ce qu’il déploie mon Foo \ Bar. Je devais le changer spécifiquement pour [DeploymentItem (@ “Foo \ Bar \”, @ “Foo \ Bar \”)] et maintenant cela fonctionne comme un charme.

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 trouvé que $ Menu> Test> Sélectionner le paramètre de test actif> Impact de la trace et du test était sélectionné. Il a commencé à fonctionner après avoir modifié l’impact de la trace et des tests sur Local . Cette page contient des informations très utiles sur la copie de fichiers dans un dossier de résultats de test, je pense également à append cette expérience.

Nous avons passé beaucoup de temps sur le problème des éléments de déploiement pour le résoudre dans le cadre du processus unittest local et de l’équipe la plus commune. Ce n’est pas facile.

ProcessExplorer est un très bon outil pour déboguer ce problème. En utilisant l’explorateur de processus, 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 sur les fichiers où chemin contient votre nom de fichier deploymentitem et vous le verrez.

Outre l’atsortingbut Deployment doit être vérifié, j’ai découvert autre chose à propos de l’atsortingbut DeploymentItem.

 [TestMethod()] [DeploymentItem("fodler\subfolder\deploymentFile.txt")] public void TestMethod1() { ... } 

Votre deploymentFile.txt doit être relavé au fichier de solution et non à testfile.cs.

entrer la description de l'image ici

N’utilisez pas DeploymentItem .

Il est très difficile à configurer correctement et il ne fonctionnait pas avec mon exécuteur de test ReSharper ni celui natif pour MSTEST dans Visual Studio 2017.

Au lieu de cela, cliquez avec le bouton droit sur votre fichier de données et sélectionnez les propriétés . 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à.