c# - Problèmes avec l'attribut DeploymentItem



visual-studio unit-testing (14)

N'utilisez pas DeploymentItem .

Il est très difficile à configurer correctement et cela ne fonctionnait pas avec mon runner de test ReSharper ni avec celui 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 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 n'ai aucune idée si cela fonctionne bien avec les systèmes automatisés de construction et de test. Je ne suis pas encore là.

Je suis en train de maintenir un "ancien" système écrit en C # .net, supprimant certaines fonctionnalités obsolètes et faisant du refactoring. Dieu merci, le gars précédent a écrit quelques tests unitaires (MSTests). Je suis plutôt à l'aise avec les tests JUnit, mais je n'en ai pas fait 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 métier en cours de test et un second DeploymentItem où seul un chemin a été spécifié contenant un tas de fichiers TIF qui doivent également être déployés.

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

Les tests fonctionnaient avant, mais maintenant je devais 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 j'ai dû changer les noms de fichiers afin de les adapter aux nouvelles exigences et soudainement les fichiers TIF ne sont plus déployés comme avant.

Quelqu'un peut-il me donner un indice pourquoi cela arrive ou quelle peut être la cause? La même chose se produit également si j'ajoute un nouveau fichier texte dit "my2ndTest.txt" à côté de "valid_entries.txt" dans le répertoire \ files \ valid \ avec l'attribut DeploymentItem correspondant à la méthode de test. Le fichier n'est pas déployé?

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


Après avoir essayé toutes les autres suggestions énumérées ici, je ne pouvais toujours pas comprendre ce qui se passait. Finalement, j'ai découvert qu'il n'y avait pas de fichier de paramètres sélectionné dans le menu Test / Test Settings, ce qui signifiait que Deployment n'était pas activé. J'ai cliqué sur l'élément de menu Paramètres de test / test / Sélectionner le fichier de paramètres de test, j'ai sélectionné le fichier Local.TestSettings, puis tout a fonctionné.


Dans VS2010, mon Local.testsettings avait la case "Enable Deployment" décochée et l'attribut DeploymentItem ne fonctionnait pas. Je l'ai vérifié et tout a bien fonctionné. J'espère que ça aide!


Depuis que j'ai toujours trouvé l'attribut DeploymentItem un désordre, je fais le déploiement de tels 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 post-build de votre projet de test pour copier les fichiers du dossier cible de génération (Bin \ Debug) vers l'emplacement où votre test les attend.


Essayez ceci pour VS2010. Vous n'avez donc 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 nœud de la solution dans l'explorateur de solutions
- Ajouter -> Nouvel élément ...
- Sélectionnez le nœud Paramètres de test sur la gauche, sélectionnez l'élément sur la 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 que vous souhaitez. Il y aura un chemin relatif à la solution. Les fichiers seront mis sur. Le fichier original sont par exemple ici:

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

Quand je lance mon test unitaire, il est copié

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 le code de test, 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'y a pas besoin de choisir Toujours copier; place les fichiers dans le testproject; ajoutez des chemins codés en dur dans le code de test. Pour moi, cette solution a mieux fonctionné. J'ai essayé avec DeploymentItem, copier toujours mais ce n'était pas à mon goût.


J'ai également fait face à des problèmes similaires mais j'ai trouvé une solution simple en 3 étapes:

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

  1. Allez dans "Solutions Items / Local.testsettings"> "Déploiement"> Cochez "Enable Deployment"
  2. Si vous utilisez VS2010, assurez-vous que tous les fichiers que vous souhaitez déployer ont leur propriété "Copy To Output Folder" définie sur "Copy Always" ou "Copy if Newer"
  3. Attribuez votre TestMethod avec l'un des éléments suivants:
    • [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> dans <TargetFolder> dans le répertoire Test Run

Une note finale sur MSTest (au moins pour VS2010):

Si vous voulez que <TargetFolder> ait le même nom que <SubFolder> , l'utilisation de [DeploymentItem(@"SubFolder", @"SubFolder")] échouera silencieusement lorsque le coureur MSTest atteindra un cas idiot. C'est pourquoi vous devriez préfixer le <SubFolder> avec le <TestProjectFolder> comme ceci: [DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]


J'ai travaillé sur cela dans VS2013. Mes conclusions 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. J'ai eu ce travail sans un fichier .TestSettings du tout.
  • Spécification d'un dossier en tant que 2ème paramètre: FACULTATIF. Formes de la disposition du dossier de sortie, fonctionne très 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 fixés ceci. Je n'ai pas encore regardé les caractères d'échappement.

Un conseil que j'ai également appris à la dure: n'oubliez pas d'ajouter cet attribut à chaque test individuel. Le fichier se copie sur le premier test attribué dans le testrun, mais est resté manquant lorsque l'ordre des tests a changé et que les tests non attribués ont tenté de trouver le fichier en premier.


J'avais d'énormes 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.


L'indicateur de déploiement a été désactivé en premier. Mais même après que je l'ai activé, pour une raison inconnue, aucune DLL cible ne serait encore copiée. Accidentellement, j'ai ouvert la fenêtre Test Run et j'ai tué toutes les exécutions précédentes et magiquement, j'ai trouvé toutes les DLL et les fichiers dont j'avais besoin dans le dossier de test la prochaine fois ... Très confus.


Mon gros "gotcha" était la façon dont DeploymentItem gère les répertoires. J'utilisais la version à deux paramètres avec les deux en tant que chemin de répertoire contenant des sous-répertoires que je voulais déployer. Je ne me suis pas rendu compte initialement qu'il ne fait que copier les choses dans la racine du répertoire et non pas toute la structure de dossiers récursive!

J'ai fondamentalement eu [DeploymentItem (@ "Foo \", @ "Foo \")] et je m'attendais à déployer mon Foo \ Bar. J'ai spécifiquement dû le changer en [DeploymentItem (@ "Foo \ Bar \", @ "Foo \ Bar \")] et maintenant cela fonctionne comme un charme.


Pour aider quelqu'un d'autre à sortir: j'ai essayé toutes les suggestions ici et mon article de déploiement n'était toujours pas 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")]

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 embarqué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 ce SO Thread


Si vous allez dans votre fichier .testrunconfig et que vous décochez la case "Enable Deployment", les tests seront exécutés à leur emplacement normal, et tout fonctionnera comme lors de l'exécution de l'application en dehors d'un test unitaire.


DeploymentItem est un peu un gâchis.

Chaque fichier de votre solution aura un paramètre "Copy To Output Folder" dans VS.NET. Vous avez besoin que ce soit "Copy Always" (ou similaire) afin d'obtenir les fichiers dans le dossier de sortie.

Vérifiez que vous avez ce jeu 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 ils ne pourront pas être déployés depuis le dossier de sortie vers le dossier où MSTest le fait.

Personnellement, si j'ai les fichiers dont j'ai besoin pour mes tests unitaires, j'ai trouvé qu'intégrer ces fichiers en tant que ressources dans un assemblage, et que cet assemblage se décompose pendant les tests est 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 suis toujours d'accord avec le fait que l'utilisation de ressources embarquées implique moins de "magie" et, pour moi, rend l'étape "arrangé" de mes tests unitaires beaucoup plus explicite.





deploymentitem