Nunit: Anhängen von Dateien an das Testergebnis

Die von Ihnen erwähnte Methode ist Teil der TestContext-Klasse im Testframework von Microsoft. NUnit hat auch eine Klasse mit demselben Namen, aber sie hat keine Beziehung zur MsTest-Klasse und verfügt nicht über eine solche Methode. In NUnit gibt es keine Möglichkeit, Dateien an die Ausgabe anzuhängen.

Danke Charlie.
Aber wird die AddResultFile-Methode in Zukunft zu NUnit hinzugefügt?
Diese Methode ist wirklich hilfreich.

Es gibt derzeit keinen Plan dafür. Wenn Sie dieses Problem in eine Anfrage für eine solche Funktion umwandeln möchten, können wir dies tun und sie erneut öffnen.

Wenn ja, sollten Sie genauer erklären, wie es funktionieren würde. Wie werden Dateien erstellt, wo werden sie gespeichert usw. Fordern Sie, dass NUnit die Dateien tatsächlich erstellt oder einfach einen Verweis auf sie behält?

Natürlich müssten wir die Idee akzeptieren, priorisieren und für eine Veröffentlichung einplanen.

Danke für deine Antwort Charlie.
Es wäre toll, wenn diese Methode zu NUnit hinzugefügt würde.
es würde genau wie die AddResultFile-Methode der TestContext-Klasse im Microsoft-Testframework funktionieren.
Verknüpfen Sie das Testergebnis (Datei-HTML-Testergebnis oder Screenshot) mit der Testausgabe im Test-Explorer in VS. Sie können den Screenshot wie unten sehen.

Danke für die Idee. Ich werde das wieder öffnen.

Um es weiterzuentwickeln, müssten wir jedoch herausfinden, wie es für NUnit selbst funktioniert, nicht nur für den Adapter. Ich markiere dies als Idee, was wir als etwas bezeichnen, das nicht gut genug definiert ist, um es als zukünftiges Feature in Betracht zu ziehen. Vielleicht melden sich noch andere mit Vorschlägen.

Dinge, die wir berücksichtigen müssen:

• Wie würde das im XML-Ergebnis aussehen
• Können wir das alles irgendwie so verpacken, dass das Ergebnis und die Anhänge zusammengehalten werden?
• Was würde die NUnit-Konsole damit tun, wenn überhaupt.
• Würde die NUnit-GUI es in irgendeiner Weise anzeigen?

Diese Funktion ist ein Muss.
Wir führen unsere automatisierten Verhaltenstests mit NUnit und Selenium durch. Wenn ein Test fehlschlägt, hängen wir gerne einen Screenshot des Browsers in das Testergebnis ein: Dies ist eine große Hilfe, um den Test zu beheben.
Dazu mussten wir das Testframework von Microsoft verwenden, aber es ist nicht so leistungsfähig wie NUnit (Attribut auf Assembly- oder Klassenebene, generische Testklasse...). Wir freuen uns also auf dieses Feature in NUnit.

Ich ändere dies in ein Feature, das ein Design benötigt, das solider ist als eine Idee. Wir müssen noch die in meinem früheren Kommentar aufgeführten Fragen klären.

Ich denke, es ist entweder die Serialisierung der Datei in der XML oder das Beibehalten eines referenzierten Verzeichnisses daneben. Das eine führt zu einem riesigen XML, allgemeiner Langsamkeit und den Dateien, die einen bestimmten Interpreter erfordern, das andere führt dazu, dass Dateien von den Ergebnissen getrennt werden und die Referenzen beschädigt werden.

Welches ist das kleinere Übel? Ich habe das Gefühl, dass bei ersterem der Schmerz die Vorteile überwiegen wird, alles im Paket zu halten - und es wird ausreichen, "hoffentlich verfügbare" relative Links zu haben.

• Was würde die NUnit-Konsole damit tun, wenn überhaupt.
• Würde die NUnit-GUI es in irgendeiner Weise anzeigen?

Für die GUI sieht so etwas wie die obige Schnittstelle gut aus, nur Hyperlinks zu der angehängten Datei. Die Konsole imo sollte den Benutzer in der Meldung zum fehlgeschlagenen Test benachrichtigen, dass eine Datei und ihr Speicherort verfügbar sind.

Ich kann mir vorstellen, dass dazu jemand eine PR einreichen muss, sobald das Design ausgearbeitet ist - @fredgate , hast du Interesse? 😄

Wir sollten uns ansehen, wie MSTest die Dateien speichert. Ich gehe davon aus, dass die Visual Studio-Erweiterung einen Link zur Datei auf dem Laufwerk erfordert.

Scheint so, als ob eine Referenz in der XML der richtige Weg ist. Für NUnit ist der logische Anfangsspeicherort das Arbeitsverzeichnis, in das die XML standardmäßig verschoben wird. Das löst meine ersten beiden Punkte oben.

Beantworte meine anderen Punkte:

• Ich denke, die Konsole würde nicht mehr tun, als die Anhänge mit dem Pfad aufzulisten, genau wie bei den Ergebnissen.
• Die GUI könnte eine Art Menü oder Panel zum Auflisten von Anhängen haben. Es könnte sie anzeigen, sofern für den jeweiligen Dateityp eine Standardanwendung definiert wurde.

Scheint ein gutes Feature zu sein, das ich eher auf normale Priorität erhöhen würde.

@rprouse Erinnerst du dich, wie Gallio mit Anhängen

Was muss ein Anhangselement in Bezug auf Attribute und Elemente enthalten? Etwas wie das?

<attachments>
    <attachment  description="Final screen shot">ScreenShot.jpg</attachment>
    ...
</attachments>

Ich gehe davon aus, dass es ein Kind des Tests ist, der es produziert hat, also haben wir diese Informationen. Benutzer möchten möglicherweise mehrere Screenshots einfügen, daher die Beschreibung. Noch etwas?

Wie ist die Syntax, um etwas anzuhängen? Sollten wir TestContext verwenden? Sollte es eine Möglichkeit geben, es mit einem Assert zu verknüpfen, damit der Anhang bei einem Fehler automatisch erstellt wird?

Möchte jemand eine Spezifikation dafür schreiben?

Scheint ein gutes Feature zu sein, das ich eher auf normale Priorität erhöhen würde.

👍

@rprouse Erinnerst du dich, wie Gallio mit Anhängen

Nein, ich habe noch nie Anhänge verwendet. Dein XML-Format gefällt mir. Persönlich denke ich, dass wir mit dem Hinzufügen von Anhängen aus dem TestContext beginnen sollten, da dies der einfachere Weg ist. Wir können dann evaluieren, ob wir das auf Asserts ausweiten möchten.

Also TestContext.CurrentContext.AddAttachment ?

Mit Überladungen für (string path) und (string path, string description) ?

Vielleicht haben wir schon eine Spezifikation!

Bitte erhöhen Sie die Priorität dieser Funktion. Für unsere Zusammenfassung der Testergebnisse wäre es sehr hilfreich, UI-Screenshots anzuhängen. Wären diese Anhänge im Build-Ergebnis in VSTS (Visual Studio Team Services) verfügbar?
Vielen Dank Charlie

Ich denke, es ist ein gutes Feature und ich werde Anhänge als Build-Artefakte in TeamCity veröffentlichen

Ich habe es auf normale Priorität gesetzt, da @rprouse das bereits vorgeschlagen hatte. Beachten Sie jedoch, dass Elemente mit niedriger und normaler Priorität manchmal warten müssen, bis jemand inspiriert wird, sie zu implementieren - entweder ein NUnit-Committer oder ein Mitwirkender. Es ist eher eine persönliche Entscheidung als eine Teamentscheidung, wann es fertig ist.

Ich hoffe, das hat niemand vergessen. Das wäre eine sehr hilfreiche Funktion.

Ich denke, die vorherigen Kommentare haben alle Designprobleme gelöst, daher nehme ich das Designlabel ab und füge das Implementierungsproblem zu Backlog hinzu.

Wir haben das nicht so sehr vergessen, als dass wir eine Menge Dinge vor sich haben. Wie ich in einem früheren Kommentar erwähnt habe, sind Elemente mit normaler Priorität wie diese nicht Teil unserer Release-Planung. Es liegt an einem Teammitglied oder externen Mitwirkenden, sich so zu interessieren, dass sie es übernehmen. Hoffentlich wird das Hinzufügen zum Backlog jemanden motivieren, aufzusteigen. Je nach Ihren Fähigkeiten könnten Sie das sein! 😄

tolle Funktion! wäre sehr dankbar. hoffentlich setzt das bald jemand um 😄

Ich habe gerade in Nr. 2152 eine PR für die erforderliche Framework-Funktionalität erstellt, um dies zu implementieren. Da es ein paar Leute gibt, die dieses Problem verfolgen, plane ich, dieses Problem in eine Epic- und Track-Runner-Unterstützung umzuwandeln, sobald wir uns entschieden haben, was dort zu tun ist.

Hier meine Gedanken:

VS-Adapter
Dies ist eine Funktion von MSTest, sodass das VS-Adapter-Framework bereits über Funktionen zum Anzeigen angehängter Dateien verfügt. Muss nur herausfinden, wie man das einsteckt

Konsole/NUnitLite
Ich bin hier gemischter Meinung. Bei Fehler-/Warnungstests ist es sinnvoll, den Dateipfad/die Beschreibung eines Anhangs mit dem Ergebnis anzuzeigen. Wie wäre es mit Anlagen zu bestandenen Prüfungen? Sollten wir eine 'Information'-Ausgabe haben, um diese anzuzeigen? Die Konsolen-Runner hätten also drei Arten von Ausgaben - Informationen/Warnungen/Fehler?

GUI/Xamarin
Beides sollte dies letztendlich unterstützen, aber ich glaube nicht, dass es eine hohe Priorität hat. Ich werde Probleme erstellen, sie aber nicht an dieses Epic anhängen - sie können durchgeführt werden, wenn die Nachfrage / die Zeit es zulässt.

TeamCity
@NikolayPianikov - Sie sagten, Sie

Gedanken zu all dem oben? @nunit/framework-team ? Ich werde einzelne Themen machen, sobald wir die nächsten Schritte beschlossen haben.

@ChrisMaddock Probleme können auch Designprobleme sein, also könnten Sie eines tun, das sagt "Herausfinden, wie Anhänge in der GUI unterstützt werden" - dasselbe gilt für alle anderen, bei denen Sie sich nicht sicher sind.

Für den Konsolenläufer zeigen wir derzeit nicht alle Tests, obwohl dies möglich wäre. Jeder Detailbericht kann von einer Erweiterung oder einer benutzerdefinierten XSL-Transformation verarbeitet werden. Letzteres wäre für jeden, der bereit ist, XSL-Codierung durchzuführen, trivial zu implementieren. 😄 Es könnte eine beigesteuerte Transformation sein.

NUnitLite ist knifflig, da wir es sehr leicht halten wollen. Man geht jedoch davon aus, dass die Benutzer ihre Anhänge intelligent benennen und alle im selben Verzeichnis ablegen, sodass sie leicht zu finden sein sollten. Tatsächlich funktioniert das auch für den Konsolenläufer
Ich denke, das Natürliche für die GUI ist, den Namen und die Beschreibung der Anhänge zusammen mit allem anderen über das Testergebnis anzuzeigen. Wir könnten es zu einem Link machen, wenn der Benutzer eine entsprechende Anwendung installiert hat, die die Datei öffnet.

Sobald wir Anhänge haben, ist es meiner Meinung nach sehr einfach, sie den Ergebnissen hinzuzufügen, die wir vom Adapter an Visual Studio übergeben.

Ich habe https://github.com/nunit/docs/issues/197 und https://github.com/nunit/nunit3-vs-adapter/issues/332 erstellt , um die nächsten Schritte abzudecken.

Was die Läuferunterstützung betrifft - wenn die einzigen aktuellen Anforderungen dafür die Integration mit dem VS-Adapter sind, bin ich geneigt, sie vorerst nur dort zu implementieren. Es ist eine Funktion, die besser zu grafischen Läufern passt, dann können in Zukunft immer cli - und andere Läuferunterstützung hinzugefügt werden, falls dies erforderlich ist.

@ChrisMaddock Ich würde gerne die Unterstützung von Anhängen vom Konsolenläufer sehen.

@kdubau - perfektes Timing! 😄 Wie soll es in diesem Fall aussehen? Was wäre Ihr Anwendungsfall?

Ich könnte mir vorstellen, einen Textblock "Anhänge" hinzuzufügen, um Fehler/Warnungen zu testen, Beschreibung und Dateipfad aufzulisten. Ein Grund, warum ich darüber diskutiert habe, dies nicht zu tun, ist, dass ich nicht davon überzeugt war, dass viele Benutzer einen Dateipfad aus ihrer Shell kopieren/einfügen möchten, um die entsprechende Datei zu finden. Würden Sie nicht zustimmen?

Das andere zu bedenkende Problem ist, dass die Konsole derzeit nur fehlgeschlagene/gewarnte Tests und nicht alle Tests anzeigt. Sollen wir eine dritte Ergebnisliste ('Information'?) erstellen, die alle bestandenen Tests-mit-Anhängen anzeigt?

Vielleicht wäre es tatsächlich in Ordnung, dass der Konsolenläufer nur Anhänge für fehlgeschlagene Tests anzeigt, da dies möglicherweise alles ist, was bei einem Konsolenlauf interessant ist. Ich stelle mir relevante Protokolldateien für Fehler hier vor und so.

@kdubau Anstatt es hier zu beschreiben, schlage ich vor, dass Sie ein neues Problem im Nunit-Konsolen-Repository erstellen.

@ChrisMaddock @CharliePoole Ich habe den Kontext hier möglicherweise falsch verstanden. Ich bin nur daran interessiert, dass die Anhänge in der Ausgabe-XML referenziert werden - es ist nicht erforderlich, die Anhangsinformationen tatsächlich in der Konsolenausgabe anzuzeigen. Mein Anwendungsfall besteht darin, dass mein CI-System (Visual Studio Team Services) die im XML aufgelisteten Anhänge als Build-Artefakte hochladen kann (dafür wäre nur ein Verweis auf die Datei auf der lokalen Festplatte erforderlich).

Ich war besorgt, dass das Ausführen von Tests über den Konsolenläufer die Anhänge nicht in der XML haben würde, aber beim Weiterlesen glaube ich nicht, dass dies die Frage war. Bitte korrigiere mich wenn ich falsch liege :)

@kdubau - Du hast recht. 🙂 #2152 wurde gerade zusammengeführt, was Anhänge in der Ergebnis-XML unterstützt. Wenn alles nach Plan läuft, wird dies Teil von NUnit 3.7 sein, das nächste Woche veröffentlicht wird.

Richtig... wenn wir "Unterstützung" in der Konsole benötigen, würde das bedeuten, etwas mehr zu tun, als nur das XML zu speichern, das aus dem Framework kommt. Im Fall des nunit3-Adapters definiert @ChrisMaddock , was das bedeuten wird.

Hey Leute, ist diese Arbeit erledigt oder steht sie noch an? Ich konnte keine offenen Fragen oder PRs dazu finden.

Entschuldigung, wenn ich etwas vermisse, aber meine Testanhänge werden immer noch nicht wie erwartet im VS Test Explorer angezeigt. Ich verwende NUnit3TestAdapter 3.8.0 von NuGet und die API TestContext.AddTestAttachement(file) aber ich sehe die Anhänge nicht im Test-Explorer. Ich erwarte so etwas:

Sind meine Erwartungen falsch?

@kdubau - Nein, dies sollte in NUnit v3.7 und NUnit3TestAdapter 3.8 veröffentlicht werden. Siehe https://github.com/nunit/nunit3-vs-adapter/issues/332 für die Implementierung. Dieses Problem bleibt einfach offen, da ich immer noch nicht dazu gekommen bin, die beiden erforderlichen Dokumentationssätze hinzuzufügen ...

Wenn es nicht funktioniert, würde ich Ihre Tests zuerst in der NUnit-Konsole ausführen - und prüfen, ob Ihr Anhang in der XML-Ergebnisdatei korrekt aufgezeichnet wird. Wenn nicht, öffnen Sie ein Problem in diesem Repository, wenn ja, öffnen Sie ein Problem im Adapter-Repository, und wir können weitere Untersuchungen durchführen. 🙂

@ChrisMaddock okay, Problem erstellt https://github.com/nunit/nunit3-vs-adapter/issues/373

Dank der Motivation von @kdubau habe ich dieses Feature endlich dokumentiert und kann dieses Epic schließen. 😄