Je maintiens actuellement un "ancien" système écrit en C # .net, supprimant certaines fonctionnalités obsolètes et faisant quelques refactorisations. 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 fait grand chose avec les tests MST.

Les méthodes de test ont un DeploymentItemattribut, spécifiant un fichier texte qui est analysé par la méthode de logique métier qui est testée et un 2ème DeploymentItemoù juste 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 auparavant, 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 ExistsTifTest()méthode. 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 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 dit "my2ndTest.txt" à côté du "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 maintenant déployé les images en définissant le chemin de déploiement directement dans le testrunconfig, mais j'aimerais comprendre pourquoi ces choses se produisent ou pourquoi par exemple mon nouveau fichier "my2ndTest.txt" n'est pas déployé alors que les autres le font.

DeploymentItem est un peu en désordre.

Chaque fichier de votre solution aura un paramètre «Copier dans le dossier de sortie» dans VS.NET. Vous avez besoin que ce soit "Copier toujours" (ou similaire) afin d'obtenir les fichiers dans le dossier de sortie.

Vérifiez que vous disposez de 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 du dossier de sortie vers le dossier dans lequel MSTest s'occupe de tout.

Personnellement, si j'ai des fichiers dont j'ai besoin pour mes tests unitaires, j'ai trouvé qu'incorporer ces fichiers en tant que ressources dans un assembly, et avoir cet assembly "décompressé" lui-même pendant les tests est une façon plus prévisible de faire les choses. YMMV.

Remarque: 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 reste fidèle aux commentaires selon lesquels l'utilisation de ressources embarquées implique moins de «magie» et, pour moi, rend l'étape «organiser» de mes tests unitaires beaucoup plus explicite.

Dans VS2010, mes Local.testsettings avaient la case «Activer le déploiement» 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!

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

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

1. Allez dans «Solutions Items / Local.testsettings»> «Deployment»> Cochez «Enable Deployment»
2. Si vous utilisez VS2010, assurez-vous que tous les fichiers que vous souhaitez déployer ont leur propriété «Copier dans le dossier de sortie» définie sur «Copier toujours» ou «Copier si plus récent»
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>to <TargetFolder>dans le répertoire Test Run

Une dernière remarque sur MSTest (au moins pour VS2010):

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

Pour nous l' espérons aider quelqu'un d' autre: j'ai essayé toutes les suggestions ici et encore mon point de déploiement était pas recopié.

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 sous déploiement, décochez "Activer le déploiement", les tests s'exécuteront dans leur emplacement normal et tout fonctionnera comme il le fait 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 conseils que j'ai trouvés avec l'attribut [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'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 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 / 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 "relatif au chemin du projet", ce que j'ai d'abord pris pour signifier le dossier du projet. En fait, il semble faire référence au dossier de sortie de construction. Donc, si j'ai un dossier de projet appelé 'TestFiles' et un fichier qu'il contient Testdata.xml, utiliser l'attribut de cette façon ne fonctionne pas:

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

Je peux marquer le Testdata.xmlfichier Copy Always, de sorte que la construction 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ée sur ce chemin ( TestFiles\Testdata.xml) par rapport à la sortie de la construction. Ou, je peux définir l'attribut 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é qu'en utilisant le, Copy Alwaysje rencontre parfois le même problème que j'ai lors de l'édition du fichier app.config dans un projet - si je ne change pas de code ou ne force pas une reconstruction, rien ne déclenche la copie des fichiers marqués comme être copié lors de la construction.

J'ai d'abord désactivé l'indicateur de déploiement. Mais même après l'avoir activé, pour une raison inconnue, même les DLL 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 et 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 d'énormes problèmes en essayant d'obtenir des fichiers à déployer - 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 autre test ou en rouvrant votre solution.

N'utilisez pas DeploymentItem.

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

À la place, 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.
    }

Cela semble bien fonctionner avec les systèmes de construction et de test automatisés.

Comme j'ai toujours trouvé l'attribut DeploymentItem un désordre, je fais le déploiement de ces fichiers en utilisant le script de post-construction. - Assurez-vous que les fichiers que vous souhaitez copier ont la propriété Copier toujours. - Modifiez le script de post-construction de votre projet de test pour copier les fichiers du dossier cible de construction (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
Supprimez le

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

Ajoutez une configuration de test.
- cliquez avec le bouton droit sur le nœud de 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 TDDsous TestMenu> Edit Testsettings.

Cliquez sur le déploiement. Activez-le puis ajoutez les fichiers et répertoires souhaités. Il y aura un chemin relatif à la solution. Les fichiers seront mis sur. Les fichiers d'origine sont par exemple ici:

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

Lorsque j'exécute 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 depuis:

[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; placez les fichiers dans le projet de test; ajoutez des chemins codés en dur dans le testcode. Pour moi, cette solution fonctionnait le mieux. J'ai essayé avec DeploymentItem, copiez toujours mais ce n'était pas à mon goût.

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, consultez ce fil de discussion SO

Pour moi, la cause première était autre chose: le code de production exercé 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 lorsque je les exécutais tous ensemble, le deuxième test et les suivants échouaient avec des erreurs "fichier non trouvé" (que j'avais initialement mal diagnostiquées comme étant DeploymentItem attribut ne fonctionnant pas).

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

Nous avons passé beaucoup de temps à résoudre le problème des éléments de déploiement pour le résoudre en local unittest run et teamcity unittest reun également. Ce n'est pas facile.

ProcessExplorer est un très bon outil pour déboguer ce problème . À l'aide de l'explorateur de processus, vous pouvez vérifier où Visual Studio recherche les éléments de déploiement et apporter la correction au projet. Filtrez simplement toutes les opérations de fichiers où le chemin contient le nom de fichier de votre élément de déploiement et vous le verrez.

Outre l'attribut Deployment 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 deploymentFile.txt doit être relatif au fichier de solution et non au fichier testfile.cs.

J'ai travaillé dessus dans VS2013. Mes conclusions pour que cela fonctionne:

• Copier dans le répertoire de sortie doit être défini sur Copier si plus récent / Copier toujours: OBLIGATOIRE.
• "Activer le déploiement" dans .TestSettings: NON REQUIS. Je l'ai fait fonctionner sans un fichier .TestSettings du tout.
• Spécifier un dossier comme 2ème paramètre: OPTIONNEL. Forme la disposition du dossier de sortie, fonctionne très bien sans.
• ESPACES dans le nom du fichier: cela m'a causé un mal de tête - le fichier n'a jamais été copié. La suppression des espaces a corrigé ce problème. Je n'ai pas encore examiné les personnages d'évasion.

Un conseil que j'ai également appris à la dure: n'oubliez pas d'ajouter cet attribut à chaque test individuel. Le fichier copie 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.

Mon grand "gotcha" était la façon dont DeploymentItem gère les répertoires. 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. Je n'avais pas réalisé au départ qu'il ne copiait que le contenu de la racine du répertoire et non pas toute la structure de dossiers récursifs!

J'avais essentiellement [DeploymentItem (@ "Foo \", @ "Foo \")] et je m'attendais à ce qu'il déploie mon Foo \ Bar. J'ai spécifiquement dû le changer en [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électionnez le paramètre de test actif> Trace et test d'impact a été sélectionné. Il a commencé à fonctionner après avoir changé Trace et tester l'impact en Local . Cette page contient des informations très ingénieuses sur la copie de fichiers dans le dossier des résultats des tests, je pense également ajouter cette expérience.