Ich pflege derzeit ein "altes" System, das in C # .net geschrieben ist, entferne einige veraltete Funktionen und führe einige Umgestaltungen durch. Gott sei Dank hat der Vorgänger einige Unit-Tests (MSTests) geschrieben. Ich bin ziemlich zufrieden mit JUnit-Tests, habe aber noch nicht viel mit MSTests gemacht.

Die Testmethoden haben ein DeploymentItemAttribut, das eine Textdatei angibt, die von der zu testenden Geschäftslogikmethode analysiert wird, und eine zweite, DeploymentItemin der nur ein Pfad angegeben wurde, der eine Reihe von TIF-Dateien enthält, die ebenfalls bereitgestellt werden müssen.

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

Die Tests haben vorher funktioniert, aber jetzt musste ich die Namen der TIF-Dateien im Verzeichnis \ files \ tif ändern. Gemäß einer Regel müssen die TIF-Dateinamen einem bestimmten Muster entsprechen, das auch von der ExistsTifTest()Methode überprüft wird . Jetzt musste ich die Dateinamen ändern, um sie an die neuen Anforderungen anzupassen, und plötzlich werden die TIF-Dateien nicht mehr wie zuvor bereitgestellt.

Kann mir jemand einen Hinweis geben, warum dies passiert oder was die Ursache sein kann? Das gleiche passiert auch, wenn ich eine neue Textdatei mit dem Namen "my2ndTest.txt" neben "valid_entries.txt" im Verzeichnis \ files \ valid \ mit dem entsprechenden DeploymentItem-Attribut für die Testmethode hinzufüge. Die Datei wird nicht bereitgestellt?

Ich habe die Images jetzt bereitgestellt, indem ich den Bereitstellungspfad direkt in der testrunconfig definiert habe, aber ich möchte verstehen, warum diese Dinge passieren oder warum beispielsweise meine neue Datei "my2ndTest.txt" nicht bereitgestellt wird, während die anderen dies tun.

DeploymentItem ist ein bisschen chaotisch.

Jede Datei in Ihrer Lösung verfügt in VS.NET über die Einstellung "In Ausgabeordner kopieren". Sie müssen "Immer kopieren" (oder ähnlich) sein, um die Dateien in den Ausgabeordner zu bringen.

Überprüfen Sie, ob Sie dieses Set für die neuen Dateien haben. Wenn Sie dieses Set nicht haben, werden die Dateien nicht in den Ausgabeordner kopiert und können dann nicht vom Ausgabeordner in den Ordner bereitgestellt werden, in dem MSTest sie ausführt.

Wenn ich Dateien habe, die ich für meine Komponententests benötige, habe ich festgestellt, dass das Einbetten dieser Dateien als Ressourcen in eine Assembly und das "Entpacken" dieser Assembly während der Tests eine vorhersehbarere Methode ist. YMMV.

Hinweis: Diese Kommentare basieren auf meinen Erfahrungen mit VS2010. Kommentare zu meiner Antwort deuten darauf hin, dass dies mit VS2012 kein Problem ist. Ich stehe immer noch zu Kommentaren, dass die Verwendung eingebetteter Ressourcen weniger "Magie" erfordert und für mich die "Anordnungs" -Stufe meiner Komponententests viel expliziter macht.

In VS2010 war in meinen Local.testsettings das Kontrollkästchen "Bereitstellung aktivieren" deaktiviert und das Attribut "DeploymentItem" funktionierte nicht. Ich habe es überprüft und alles hat gut funktioniert. Ich hoffe das hilft!

Ich habe auch ähnliche Probleme gehabt, aber ich habe eine einfache 3-Schritt-Lösung dafür gefunden:

Angenommen, Ihre Ordnerstruktur sieht folgendermaßen aus: SolutionFolder\ TestProjectFolder\ SubFolder\

1. Gehen Sie zu "Lösungselemente / Local.testsettings"> "Bereitstellung"> Aktivieren Sie "Bereitstellung aktivieren".
2. Wenn Sie VS2010 verwenden, stellen Sie sicher, dass für alle Dateien, die Sie bereitstellen möchten, die Eigenschaft "In Ausgabeordner kopieren" auf "Immer kopieren" oder "Bei Neuem kopieren" festgelegt ist.
3. Ordnen Sie Ihrer Testmethode Folgendes zu:
   • [DeploymentItem(@"TestProjectFolder\SubFolder")]um den gesamten Inhalt des <SubFolder>Testlaufverzeichnisses bereitzustellen
   • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")] um alle Inhalte von <SubFolder>to <TargetFolder>im Test Run-Verzeichnis bereitzustellen

Ein letzter Hinweis zu MSTest (zumindest für VS2010):

Wenn Sie möchten <TargetFolder>, dass der Name denselben Namen wie der hat <SubFolder>, [DeploymentItem(@"SubFolder", @"SubFolder")]schlägt die Verwendung stillschweigend fehl, wenn der MSTest-Läufer auf einen dummen Randfall trifft. Aus diesem Grund sollten Sie <SubFolder>dem <TestProjectFolder>as so Folgendes voranstellen :[DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Um hoffentlich jemand anderem zu helfen: Ich habe alle Vorschläge hier ausprobiert und trotzdem wurde mein Bereitstellungselement nicht kopiert.

Was ich tun musste ( wie hier vorgeschlagen ), war, dem DeploymentItem-Attribut einen zweiten Parameter hinzuzufügen:

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

Wenn Sie in Ihre .testrunconfig-Datei gehen und unter Bereitstellung die Option "Bereitstellung aktivieren" deaktivieren, werden die Tests an ihrem normalen Speicherort ausgeführt, und alles funktioniert wie beim Ausführen der App außerhalb eines Komponententests.

Dies bezieht sich wahrscheinlich nicht auf Ihr genaues Problem, aber hier sind einige Tipps, die ich mit dem Attribut [DeploymentItem] gefunden habe.

1. In das Ausgabeverzeichnis kopieren sollte auf Immer kopieren eingestellt sein.

Es funktioniert NICHT , wenn es mit dem Attribut [TestInitialize] verwendet wird

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

Es sollte sich auf Ihrer [TestMethod] befinden, z

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

    [TestMethod]
    [DeploymentItem("test.xlsx")]
    public void ExcelQuestionParser_Reads_XmlElements()
    {
        ...
    }

Nachdem ich alle anderen hier aufgeführten Vorschläge ausprobiert hatte, konnte ich immer noch nicht herausfinden, was los war. Schließlich stellte ich fest, dass im Menü Test / Testeinstellungen keine Einstellungsdatei ausgewählt war, was bedeutete, dass die Bereitstellung nicht aktiviert war. Ich klickte auf den Menüpunkt Test / Testeinstellungen / Testeinstellungsdatei auswählen, wählte die Datei Local.TestSettings aus und dann funktionierte alles.

Ich bin mir nicht sicher, ob dies die Frage genau beantwortet, aber es kann einigen helfen. Zuerst habe ich festgestellt, dass das Kontrollkästchen "Bereitstellung aktivieren" aktiviert sein muss, damit die Bereitstellung funktioniert. Zweitens sagt das Dokument, dass der Quellpfad "relativ zum Projektpfad" ist, was ich zunächst als Projektordner verstanden habe. Tatsächlich scheint es sich auf den Build-Ausgabeordner zu beziehen. Wenn ich also einen Projektordner mit dem Namen 'TestFiles' und eine Datei Testdata.xmlmit dem Namen 'TestFiles' habe, funktioniert die Verwendung des Attributs auf diese Weise nicht:

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

Ich kann die Testdata.xmlDatei markieren Copy Always, so dass der Build eine Kopie unter den Ausgabeordner legt (z Debug\TestFiles\TestData.xml. B. ). Der Bereitstellungsmechanismus findet dann die Kopie der Datei, die sich unter diesem Pfad ( TestFiles\Testdata.xml) relativ zur Build-Ausgabe befindet. Oder ich kann das Attribut folgendermaßen festlegen:

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

und der Bereitstellungsmechanismus findet die Originaldatei. Copy AlwaysBeides funktioniert also, aber ich habe festgestellt, dass bei Verwendung der Datei app.config in einem Projekt gelegentlich dasselbe Problem auftritt wie beim Bearbeiten der Datei app.config. Wenn ich keinen Code ändere oder keine Neuerstellung erzwinge, wird durch nichts das Kopieren von Dateien ausgelöst, für die markiert ist beim Build kopiert werden.

Ich hatte zuerst das Bereitstellungsflag deaktiviert. Aber selbst nachdem ich es aktiviert hatte, wurden aus einem unbekannten Grund noch nicht einmal Ziel-DLLs kopiert. Aus Versehen habe ich das Testlauffenster geöffnet und alle vorherigen Läufe beendet. Auf magische Weise habe ich beim nächsten Lauf alle DLLs und Dateien gefunden, die ich im Testordner benötigte ... Sehr verwirrend.

Ich hatte große Probleme beim Versuch, Dateien zum Bereitstellen zu bringen - ich habe alle oben genannten Vorschläge ausprobiert.

Dann habe ich VS2010 geschlossen; startete es neu, lud die Lösung und alles funktionierte. (!)

Ich habe nachgesehen; Nachdem Sie das Flag 'Bereitstellung aktivieren' auf local.TestSetting gesetzt haben, sollten Sie den Test nicht einfach über das Fenster Testergebnisse erneut ausführen. Sie müssen den vorherigen Testlauf von der Benutzeroberfläche entfernen, z. B. indem Sie einen anderen Test ausführen oder Ihre Lösung erneut öffnen.

Nicht benutzen DeploymentItem.

Die korrekte Einrichtung ist sehr schwierig und funktionierte weder mit meinem ReSharper-Testläufer noch mit dem nativen für MSTEST in Visual Studio 2017.

Klicken Sie stattdessen mit der rechten Maustaste auf Ihre Datendatei und wählen Sie Eigenschaften aus . Wählen Sie In Ausgabeverzeichnis kopieren: Immer .

Tun Sie dies jetzt in Ihrem Test. Das Verzeichnis ist einfach das Verzeichnis der Datei relativ zum Testprojekt. Einfach.

    [TestMethod()]
    public void ParseProductsTest()
    {
        // Arrange
        var file = @"Features\Products\Files\Workbook_2017.xlsx";
        var fileStream = File.Open(file, FileMode.Open);
        // etc.
    }

Dies scheint mit automatisierten Build- und Testsystemen gut zu funktionieren.

Da ich das DeploymentItem-Attribut immer als problematisch empfunden habe, verwende ich die Bereitstellung solcher Dateien mithilfe des Post-Build-Skripts. - Stellen Sie sicher, dass für die Dateien, die Sie kopieren möchten, die Eigenschaft Immer kopieren festgelegt ist. - Ändern Sie das Post-Build-Skript Ihres Testprojekts, um die Dateien aus dem Build-Zielordner (Bin \ Debug) an den Speicherort zu kopieren, an dem Ihr Test sie erwartet.

Versuchen Sie dies für VS2010. So brauchen Sie nicht DeployItems hinzufügen für jeden tif
des Entfernens

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

Fügen Sie eine Testkonfiguration hinzu.
- Klicken Sie im Lösungs-Explorer mit der rechten Maustaste auf den Lösungsknoten.
- Hinzufügen -> Neues
Element ... - Wählen Sie links den Knoten Testeinstellungen und rechts das Element.
- Klicken Sie auf Hinzufügen

Nennen wir es zB TDD

Wählen Sie TDDunter TestMenu> Edit Testsettings.

Klicken Sie auf die Bereitstellung. Aktivieren Sie es und fügen Sie dann die gewünschten Dateien und Verzeichnisse hinzu. Es gibt einen Pfad relativ zur Lösung. Die Dateien werden angelegt. Die Originaldatei ist zum Beispiel hier:

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

Wenn ich meinen Unit-Test durchführe, wird er kopiert

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  

im Testcode nenne ich es von:

[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()  
{  
  string authorityFile = "Authority.xml";  
  var Xmldoc = XDocument.Load(authorityFile);  

Es ist nicht erforderlich, Immer kopieren zu wählen. Legen Sie die Dateien in das Testprojekt. Fügen Sie dem Testcode fest codierte Pfade hinzu. Für mich hat diese Lösung am besten funktioniert. Ich habe versucht, mit DeploymentItem immer zu kopieren, aber es war nicht nach meinem Geschmack.

Für diejenigen, die es vorziehen, das Durcheinander von DeploymentItem zu vermeiden und den von @Martin Peck vorgeschlagenen Ansatz zu wählen (akzeptierte Antwort), können Sie den folgenden Code verwenden, um auf den Inhalt der eingebetteten Ressource zuzugreifen:

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();
    }
}

Einzelheiten finden Sie in diesem SO-Thread

Für mich war die Hauptursache etwas ganz anderes: Der von meinen Tests ausgeübte Produktionscode war das Umbenennen und / oder Löschen der bereitgestellten XML-Testdatei.

Wenn ich meine Tests einzeln ausführen würde, würden sie bestanden, aber wenn sie alle zusammen ausgeführt würden, würden der zweite und der nachfolgende Test mit "Datei nicht gefunden" -Fehlern fehlschlagen (die ich ursprünglich als DeploymentItemnicht funktionierendes Attribut falsch diagnostiziert hatte ).

Meine Lösung bestand darin, dass jede einzelne Testmethode eine Kopie der bereitgestellten Datei erstellt (unter Verwendung dieser Technik ) und der getestete Produktionscode dann die kopierte Datei anstelle des Originals verwendet.

Wir haben viel Zeit mit dem Problem der Bereitstellungselemente verbracht, um es im lokalen Lauf und in der Teamunity-Wiedervereinigung zu lösen. Es ist nicht einfach.

Ein sehr gutes Tool zum Debuggen dieses Problems ist ProcessExplorer . Mit dem Prozess-Explorer können Sie überprüfen, wo Visual Studio nach den Bereitstellungselementen sucht, und das Projekt korrigieren. Filtern Sie einfach alle Dateivorgänge, in denen der Pfad Ihren Deploymentem-Dateinamen enthält, und Sie werden ihn sehen.

Neben dem Deployment-Attribut, das überprüft werden muss, habe ich noch etwas anderes über das DeploymentItem-Attribut entdeckt.

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

Ihre DeploymentFile.txt muss relativ zur Lösungsdatei und nicht zur testfile.cs sein.

Ich habe in VS2013 daran gearbeitet. Meine Erkenntnisse, um dies zum Laufen zu bringen:

• In das Ausgabeverzeichnis kopieren sollte auf Kopieren gesetzt sein, wenn Neu / Immer kopieren: OBLIGATORISCH.
• "Bereitstellung aktivieren" in .TestSettings: NICHT ERFORDERLICH. Ich habe dies ohne eine .TestSettings-Datei überhaupt zum Laufen gebracht.
• Angeben eines Ordners als 2. Parameter: OPTIONAL. Formt das Layout des Ausgabeordners und funktioniert ohne.
• SPACES im Dateinamen: Dies verursachte mir Kopfschmerzen - die Datei wurde nie kopiert. Das Entfernen der Leerzeichen hat dies behoben. Ich habe noch keine Fluchtcharaktere untersucht.

Ein Tipp, den ich auch auf die harte Tour gelernt habe: Vergessen Sie nicht, dieses Attribut jedem einzelnen Test hinzuzufügen. Die Dateikopien des ersten zugewiesenen Tests im Testlauf wurden jedoch nicht angezeigt, als sich die Reihenfolge der Tests änderte und nicht zugeordnete Tests versuchten, die Datei zuerst zu finden.

Mein großes "Gotcha" war die Art und Weise, wie DeploymentItem Verzeichnisse verarbeitet. Ich habe die Zwei-Parameter-Version mit beiden als Verzeichnispfad verwendet, der Unterverzeichnisse enthält, die ich bereitstellen wollte. Mir war anfangs nicht klar, dass es nur das Zeug in den ROOT des Verzeichnisses kopiert und nicht die gesamte rekursive Ordnerstruktur!

Ich hatte im Grunde [DeploymentItem (@ "Foo \", @ "Foo \")] und erwartete, dass es meine Foo \ Bar bereitstellen würde. Ich musste es speziell in [DeploymentItem (@ "Foo \ Bar \", @ "Foo \ Bar \")] ändern und jetzt funktioniert es wie ein Zauber.

Ich habe auch ähnliche Probleme gehabt. Ich habe alle oben genannten Schritte, aber immer noch kein Glück. Ich benutze VS2010. Dann habe ich festgestellt, dass $ Menü> Test> Aktive Testeinstellung auswählen > Trace und Test Auswirkung ausgewählt wurde. Es begann zu funktionieren, nachdem ich Trace und Test Impact auf Local geändert hatte . Diese Seite enthält sehr einfallsreiche Informationen zum Kopieren von Dateien in den Testergebnisordner. Ich möchte diese Erfahrung ebenfalls hinzufügen.