Nunit: Unterstützung von `dotnet test` in .NET CLI und .NET Core

Wir haben darauf gewartet, dass sich .NET Core ein wenig beruhigt hat, bevor wir mit #927 fortgefahren sind. Aus diesem Grund wurde es nicht mit einem neuen Titel und neuen Informationen aktualisiert. Ich hatte vor, auf Ankündigungen zu warten, die bei //build herauskommen, bevor ich fortfahre, aber wir würden uns über jede Hilfe freuen, die wir bekommen können. Mein Plan ist es, in diesem Sommer mit der Version 3.4, einschließlich .NET Core, UWP und Xamarin, eine umfassendere Unterstützung für weitere Plattformen bereitzustellen.

Sie haben hier eine gut geschriebene Zusammenfassung bereitgestellt, daher werde ich #927 schließen und dieses Problem für die zukünftige Verfolgung verwenden. Wenn Sie bei diesem Problem helfen möchten, können wir uns koordinieren, aber ich würde mich über Ihre Hilfe freuen.

Der erste Schritt in diesem Prozess bestand darin, einen PCL-Treiber/-Agenten zu erstellen, der Tests laden und ausführen kann, ohne eng an eine bestimmte Version des NUnit-Frameworks wie NUnitLite und den aktuellen Xamarin-Runner gebunden zu sein. Es steckt noch in den Kinderschuhen, aber die Arbeit befindet sich im nunit.portable.agent- Projekt.

Jede Hilfe oder jeden Rat, den @piotrpMSFT oder @livarcocc geben kann, wäre auch dankbar :smile:

@rprouse Ich habe einen Fehler in der CLI, um eine bessere Dokumentation zu den Interaktionen und Anforderungen zwischen dotnet test und dem Runner zu schreiben. Ich werde es heute oder morgen erledigen und hier einen Link dazu setzen.

Dies ist die Fehlerverfolgung: https://github.com/dotnet/cli/issues/1803.

Wie geht das? Ich würde das gerne nutzen, und das Dotnet-Cli-Ökosystem scheint sich zu stabilisieren.

Ich mache einige Fortschritte, aber ich möchte nicht zu viel tun, bis RC2 fällt. Ich habe es satt, mit den Veränderungen Schritt zu halten :smile:

.NET Core RC2 wurde veröffentlicht und neue Informationen sind verfügbar. Links zum Nachschlagen.

• dotnet-test-Befehl
• Kommunikationsprotokoll dotnet-test

Kann ich hier irgendjemandem helfen? Dies ist ein Blocker, um einige unserer Ports wie StackExchange.Redis zu vervollständigen.

@NickCraver Ich könnte definitiv etwas Hilfe gebrauchen, das erste Lesen des Kommunikationsprotokolls hat die Dinge nicht so klar gemacht :smile:

Die ersten Schritte entscheiden, wie wir das angehen. Wir haben derzeit den portablen Build, der auf .NET Core abzielt, aber er ist begrenzt. Ich erwäge, einen Core-Build des Frameworks zu erstellen, bin mir aber nicht sicher, ob ich das brauche oder soll.

Dann muss ich mir ansehen, was es braucht, um eine Testerweiterung für den Befehl dotnet zu erstellen.

Schließlich möchte ich, dass die Nunit-Engine einen zentralen Nunit-Agent starten und mit ihm kommunizieren kann, damit nunit3-console .NET Core-Komponententests ausführen kann. Ich habe daran gearbeitet, habe aber noch viel zu tun.

Wie möchten Sie helfen?

@rprouse Ich denke, Sie müssen einen Core-Build haben, um möglicherweise plattformübergreifend verwendet zu werden, das ist eine kritische Funktion.

Ich bin mir nicht sicher, wie viel Zeit wir dafür investieren können, aber um ehrlich zu sein, angesichts der Menge an Arbeit, die noch übrig ist. Im Moment muss ich Bibliotheken für viele nachgelagerte Leute zur Verfügung stellen, die darauf warten, ihre Bibliotheken und Apps zu erstellen. Ich sage das ungern, aber angesichts der Verzögerung hier im Vergleich zu dem, was heute verfügbar ist, müssen wir meiner Meinung nach alles auf xUnit portieren, sonst warten viele Hundert bis Tausende von Entwicklern hier auf eine blockierte Kette von Releases.

Ich werde versuchen, dies erneut zu besuchen, sobald wir stabil sind und die Zeit es zulässt, aber (und korrigieren Sie mich, wenn ich falsch liege) im Moment sprechen wir über noch Wochen Arbeit (nach Ihrem Posten), bevor ich' d in der Lage sein, dies zu verwenden, um fertige Bibliotheks-Ports auszuführen, die zum Versand bereit sind. Aus der Sicht der Autorenpflicht muss ich zuerst Leute auf mir freigeben und dann dem Upstream helfen, so gut ich kann.

@NickCraver Anstatt den Aufwand für die Portierung auf xUnit Testen von .NET Core mit NUnit 3 darüber gebloggt, wie es geht.

Ich mache es so für ein paar persönliche Projekte und es ist funktional.

Ich würde gerne helfen, einen richtigen Dotnet-Test-Nunit-Build zu bekommen. Ich bin sicher, viele Leute würden davon profitieren. Ein Großteil des im Protokoll definierten Vertrags ist bereits in einer Hilfsbibliothek implementiert. Wenn wir einen funktionierenden xplat Nunit-Runner haben, sollte dies wenig Arbeit sein.

Würde es helfen, dies in zwei Phasen zu unterteilen - eine Art "Quick and Dirty, vielleicht grottige Hacks, aber lass uns wenigstens etwas rausbringen"-Release und später eine umfassendere Integration?

(Allein im Begriff, die Tests mit einem TFM von netstandard1.3 zu erstellen, würde mich zum Beispiel für Noda Time entsperren.)

@jskeet und @NickCraver können Sie NUnit heute über den NUnitlite "Hack" verwenden, wie @rprouse vorgeschlagen hat, ich mache dies seit einiger Zeit für Npgsql und es funktioniert gut. Es ist nicht die perfekte Lösung, aber es sollte euch definitiv entsperren.

@roji : Das hat mit dnxcore50 funktioniert (ich benutze es schon seit einiger Zeit mit Noda Time) - aber mit netstandard1.3 sind die Abhängigkeiten von NUnit und NUnitLite ungültig.

@jskeet mein Testprojekt zielt auf netcoreapp1.0 ab und hängt von Nunit+NUnitLite 3.2.1 ab. Ich habe "imports" : [ "dotnet54" ] und es funktioniert wie ein Zauber...

@roji : Danke dafür... Daumen

@roji : Ich habe immer noch Probleme, die Tests tatsächlich

@jskeet sicher, los gehts: https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.Tests

@jskeet die Importe sollten auch für Sie funktionieren. RC2 ändert ein paar Dinge, daher werde ich meinen Blogbeitrag zum Testen mit NUnit 3 unter Berücksichtigung von RC2 neu schreiben und den Code auf GitHub posten. Ich werde hier einen Link hinzufügen, wenn es fertig ist, hoffentlich heute Morgen (EST).

@piotrpMSFT können Sie mir etwas Zeit sparen und mich auf die dotnet-test-nunit verweisen? Ich kann suchen, aber ich verfolge im Moment mehrere Dinge, daher wäre ich dankbar für Hilfe. Ich bin sicher, Sie sind auch beschäftigt, also wenn Sie es nicht zur Hand haben, verbringen Sie keine Zeit damit, ich werde es finden.

Für alle Interessierten habe ich einen aktualisierten Blogbeitrag zum Testen von .NET Core RC2 mit NUnit 3 veröffentlicht .

@jskeet Sie benötigen die imports-Anweisung in Ihrer project.json. Es wird standardmäßig in den neuen .NET Core-Vorlagen hinzugefügt, muss jedoch beim Upgrade hinzugefügt werden.

Für project.json in einem Konsolen-Runner;

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }

Oder in einer Versammlung;

  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"
    }

Beim Upgrade auf RC2 hat mich auch das alte DNX-Zeug in meinem Weg gebissen. Etwas zu überprüfen.

@rprouse : Danke; Ich kann jetzt bauen und die Tests laufen unter Windows. Unter Linux sehe ich eine "Objektreferenz nicht auf eine Instanz eines Objekts festgelegt". Nachricht auf dotnet run , die ich weiter untersuchen muss. Werde dein Minimalbeispiel ausprobieren, um zu sehen, ob das das gleiche Problem hat...

@jskeet , wir verwenden diesen Ansatz sowohl unter Windows als auch unter Linux ohne hier und hier .

@oschwald : Yup, es sieht so aus, als ob das Problem mit dem "Objektverweis nicht gesetzt ..." ein sehr separates Problem mit Abhängigkeiten ist. Es ist eine Schande, dass die Fehlermeldung so wenig hilfreich ist (ohne auch nur einen Stack-Trace) - ich grabe mich darin ein.

@jskeet Es gibt ein paar Ursachen, ist das deine? https://github.com/dotnet/cli/issues/3075

@NickCraver : Nein - ich habe erfolgreich eine Dotnet-Wiederherstellung durchgeführt.

In meinem Fall habe ich eine Datei project.json, die ohne Abhängigkeit von einem anderen Projekt funktioniert, aber damit fehlschlägt. Ich muss noch etwas Zeit investieren, um eine komplette Repro zu erstellen.

@jskeet Gotcha - relevant: https://github.com/dotnet/cli/issues/2469 und der Slack-Kanal ist großartig für project.json Live-Debugging, kommen Sie mit Beispielen vorbei und Sie können normalerweise ziemlich schnell loslegen. Für Slack sind die Kanäle #general und #dotnet-core ziemlich aktiv, viele Leute machen das durch und helfen der nächsten Person.

Hmm... und jetzt funktioniert es. Es ist möglich, dass es das gleiche Problem war, das @NickCraver gemeldet hat, und dass ich nur das falsche Projekt dotnet restore -ing, um es zu beheben. Wie auch immer, ich führe jetzt Noda Time Tests unter Linux durch, also yay :) Vielen Dank an alle.

@piotrpMSFT Zu meiner Bitte um

Ich habe eine erste PR für den dotnet-test-nunit Läufer bei nunit/dotnet-test-nunit#1 hinzugefügt

Es untersucht und führt Tests durch, erfordert jedoch noch einige Arbeit, Bereinigung und Tests. Ich werde den NuGet-Feed für die Build-Artefakte zugänglicher machen, wenn jemand damit spielen möchte.

Wenn jemand Ideen hat, wie ich das NuGet-Paket debuggen kann, wenn es von Visual Studio geladen wird, könnte ich etwas Hilfe gebrauchen. Bisher wird es nicht in Visual Studio ausgeführt, aber das könnte ein Setup-Problem sein.

@rprouse : Ich würde gerne sehen, wie Noda Time damit umgeht, wenn das nützlich wäre. Lassen Sie mich wissen, wenn ich etwas Bestimmtes überprüfen möchte. Danke für deine ganze Arbeit!

Es ist noch nicht bereit für die Hauptsendezeit, aber ich habe NUnit .NET Core-Tests in der Konsole und in Visual Studio ausgeführt. Es sind noch einige Probleme zu lösen, bevor ich eine Alpha herausbekomme, aber wir sind uns jetzt viel näher gekommen, da die harte Arbeit abgeschlossen ist und es auf die Details ankommt.

Ich werde Details zum Testen mit dem CI-Build veröffentlichen, nachdem ich einige Probleme behoben habe. Ich würde es begrüßen, wenn die Leute gegen die Reifen treten und mir helfen könnten, Probleme zu finden.

Hier ist ein Screenshot.

@rprouse : Irgendwelche Fortschritte beim CI-Build? Auf jeden Fall daran interessiert, die Reifen zu treten; Noda Time verwendet eine _angemessene_ Anzahl von NUnit-Funktionen, daher sollte es auf jeden Fall ein guter Anfang sein. Ich freue mich sehr darauf, wieder Tests in VS durchführen zu können. (Ich hoffe, NCrunch und CodeRush für Roslyn werden es auch unterstützen, sobald es herauskommt ...)

@jskeet und andere, die daran interessiert sind, in die Reifen zu treten und mir beim Testen zu helfen, bevor ich eine Alpha veröffentliche, habe ich mein Demo-Repository in einem dotnet-test-nunit Zweig aktualisiert , um den neuen dotnet-test-nunit Runner zu verwenden.

Bitte melden Sie Probleme im nunit/dotnet-test-nunit Repo .

High-Level-Anweisungen sind;

Update: dotnet-test-nunit ist jetzt als Alphaversion auf NuGet verfügbar, wählen Sie Include prereleases . Sie müssen Ihre nuget.config Datei nicht mehr aktualisieren.

dotnet-test-nunit befindet sich noch in der Entwicklung, daher müssen Sie Ihrer Lösung eine Datei NuGet.Config hinzufügen, um NuGet-Pakete aus den NUnit CI NuGet-Feeds herunterzuladen.

Ihr project.json in Ihrem Testprojekt sollte wie folgt aussehen;

project.json

{
    "version": "1.0.0-*",

    "dependencies": {
        "NUnitWithDotNetCoreRC2": "1.0.0-*",
        "NETStandard.Library": "1.5.0-rc2-24027",
        "NUnit": "3.2.1",
        "dotnet-test-nunit": "3.4.0-alpha-1"
    },
    "testRunner": "nunit",

    "frameworks": {
        "netstandard1.5": {
            "imports": [
                "dnxcore50",
                "netcoreapp1.0",
                "portable-net45+win8"
            ]
        }
    },

    "runtimes": {
        "win10-x86": { },
        "win10-x64": { }
    }
}

Die interessantesten Linien sind hier die Abhängigkeit von dotnet-test-nunit . Fühlen Sie sich frei, die neueste Pre-Release-Version zu verwenden, die auf -CI endet, die spätestens aus dem Master-Zweig stammt. Beachten Sie, dass die Abhängigkeit von NUnitWithDotNetCoreRC2 das getestete Projekt ist.

Ich habe "testRunner": "nunit" hinzugefügt, um NUnit 3 als Testadapter anzugeben. Ich musste auch die Importe sowohl für den Testadapter als auch für NUnit zum Auflösen hinzufügen. Zuletzt musste ich die runtimes hinzufügen. Wenn jemand erklären kann, warum ich das tun muss, lass es mich wissen.

Sie können Ihre Tests jetzt mit dem Visual Studio-Test-Explorer oder durch Ausführen von dotnet test über die Befehlszeile ausführen.

# Restore the NuGet packages
dotnet restore

# Run the unit tests in the current directory
dotnet test

# Run the unit tests in a different directory
dotnet test .\test\NUnitWithDotNetCoreRC2.Test\

Warnung

Wie gesagt, das ist noch in der Entwicklung. dotnet-test-nunit Version 3.3.0.39-CI hat einen Fehler, bei dem ein ArgumentException ausgegeben wird, wenn versucht wird, die TestResult.xml Datei zu speichern.

Beachten Sie auch, dass die Befehlszeile dotnet Leerzeilen schluckt und nicht mit Farbe funktioniert. Die Ausgabe des NUnit-Testläufers ist in Farbe, aber Sie werden sie nicht sehen.

Der Teil "Leerzeilenschlucken" ist ein bekannter Fehler: https://github.com/dotnet/cli/issues/2234

Danke für den Link @jskeet , Farbe scheint auch ein bekannter Fehler zu sein, dotnet/cli#1977

Das ArgumentException wurde in 3.3.0.49-CI behoben. Ich werde meine obigen Anweisungen mit dem Fix aktualisieren. Ein weiteres offenes Problem besteht darin, dass ich dem Runner derzeit keine Zeilennummer für Tests liefere. Wenn Sie also im Visual Studio-Test-Explorer auf Tests klicken, gelangen Sie nicht zum Code.

Habe ich Recht, wenn ich sage, dass es noch keine Unterstützung für Befehlszeilenargumente wie --where usw. gibt? (Ich verstehe voll und ganz, dass es noch am Anfang ist - versuche nur zu überprüfen, ob ich dazu in der Lage sein sollte.)

Ich habe ein etwas anderes project.json ausprobiert. Ich habe es unten wörtlich aufgenommen, aber die wichtigen Unterschiede sind:

• Ich möchte auch die Desktop-Laufzeit testen, also habe ich zwei Framework-Ziele
• Ich verwende netcoreapp1.0 anstelle von netstandard1.5
• Ich habe die Abhängigkeit von Microsoft.NETCore.App mit "type"="platform"
• Schau ma, kein Laufzeitabschnitt. (Möglicherweise aufgrund einiger der oben genannten Änderungen...)

{
  "buildOptions": {
    "keyFile": "../../NodaTime Release.snk",
    "embed": {
      "include":  [   
        "TestData/*"
      ]
    }
  },

  "configurations": {
    "Debug": {
      "buildOptions": {
        "define": [ "DEBUG", "TRACE" ]
      }
    },
    "Release": {
      "buildOptions": {
        "define": [ "RELEASE", "TRACE" ],
        "optimize": true
      }
    }
  },

  "dependencies": {
    "NodaTime": { "target": "project" },
    "NodaTime.Testing": { "target": "project" },
    "NUnit": "3.2.1",
    "dotnet-test-nunit": "3.3.0.49-CI",
    "Microsoft.CSharp": "4.0.1-rc2-24027",
    "System.Dynamic.Runtime": "4.0.11-rc2-24027",
    "System.Reflection.Extensions": "4.0.1-rc2-24027",
    "System.Xml.XDocument": "4.0.11-rc2-24027"
  },

  "testRunner": "nunit",

  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Threading.Tasks": "",
        "System.Xml.Linq": ""
      }
    },
    "netcoreapp1.0": {
      "imports" : [ "dnxcore50", "netcoreapp1.0", "portable-net45+win8" ],
      "buildOptions": {
        "define": [ "PCL" ]
      },
      "dependencies": {
        "Microsoft.NETCore.App": { 
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        },
        "System.Console": "4.0.0-rc2-24027",
      }
    }
  }
}

Ergebnis:

Test Count: 15141, Passed: 15141, Failed: 0, Inconclusive: 0, Skipped: 0

Wow. (Mit net451 erhalte ich eine Testanzahl von 15646, was ich erwarten würde.)

Als nächstes: Versuchen Sie dasselbe auf einem Linux-Computer (wo Ihr project.json vermutlich nicht ohne Modifikation funktionieren würde, da es Linux nicht erwähnt, aber meiner sollte theoretisch; obwohl es ein Ubuntu 16.04-Computer ist, also ist es dotnet CLI ist etwas zusammengewürfelt).

Hmm. Tests unter Linux waren nach 14 Minuten voller CPU-Fressung noch nicht abgeschlossen. Muss noch genauer hinschauen, was da passiert.

@jskeet

Habe ich Recht, wenn ich sage, dass es noch keine Unterstützung für Befehlszeilenargumente wie --where usw. gibt?

Schlecht getestet, aber ich habe --where und die meisten gängigen Befehlszeilenparameter verdrahtet. Ich habe immer noch ein Problem, nunit/dotnet-test-nunit#4, um zu überprüfen, ob sie alle richtig verkabelt sind und funktionieren, und alle fehlenden hinzuzufügen. Bisher habe ich nicht viele getestet, aber ich habe einige verwendet, indem ich sie am Ende des Befehls dotnet hinzugefügt habe. Wie das genau funktioniert, muss ich aber noch herausfinden. Zum Beispiel hat die Befehlszeilenoption --debug der dotnet-test-nunit Lösung gut funktioniert, aber sie wirft dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" wenn ich sie von meiner Testlösung aus ausführe. Ich habe auch keine Ahnung, wie ich die Hilfe-Befehlszeile mit unserer verketten kann, um zu zeigen, was unterstützt wird.

In der Zwischenzeit können Sie einen Blick auf https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs werfen, um zu sehen, welche Befehlszeilenoptionen meiner Meinung nach sind unterstützt :smile:

Ah, ja - es sieht so aus, als hätte dotnet test nicht die gleiche Möglichkeit wie dotnet run um Argumente für das Testframework von Argumenten an dotnet test selbst zu trennen. ich hatte versucht

dotnet test -- --help

und

dotnet test -- --where=cat!=Slow

Einfach verwenden

dotnet test --where=cat!=Slow

funktioniert gut. Werde dafür eine Feature-Anfrage stellen - es ist schön, völlig eindeutig sein zu können.

Das Klicken auf Tests und das Navigieren zum Code ist jetzt in 3.3.0.60-CI behoben.

Es gibt immer noch zwei Probleme mit hoher Priorität, dann plane ich eine Alpha-Version, an der ich dieses Problem schließen und alles im neuen Repository verfolgen werde. Die beiden Probleme sind;

• [x] nunit/dotnet-test-nunit#22 Hinzufügen von Nachrichten und Stapeln von Traces zu fehlgeschlagenen Tests
• [x] nunit/dotnet-test-nunit#12 TestContext.WriteLine wird nicht in der Testzusammenfassung von TestExplorer angezeigt

Nur als FYI habe ich die Noda Time-Tests heute erneut auf meiner Ubuntu-Box durchgeführt und sie waren nach etwa 15 Minuten abgeschlossen. Sieht so aus, als ob sie auf meinem Linux i5 etwa 5-6x langsamer laufen als auf meinem Win10 i7. Ich bin mir jedoch nicht sicher, wie viel das mit CPU und wie viel mit JIT zu tun hat - und es liegt definitiv außerhalb des Rahmens von NUnit :)

@jskeet danke für das Update, das sind gute Nachrichten. Haben Sie für die Linux-Tests Monobindungen benötigt, wie in nunit/dotnet-test-nunit#9 angegeben?

Für alle, die testen, ist das neueste gute NuGet-Paket 3.3.0.69-CI , bitte testen Sie damit. Es gibt jetzt kein offenes Problem, das meiner Meinung nach schwerwiegend genug ist, um eine Veröffentlichung zu blockieren. Wenn diese Woche keine gemeldet werden, werde ich wahrscheinlich Ende dieser Woche oder Anfang nächster Woche eine Alpha-Version erstellen. Sobald ich das getan habe, werde ich dieses Problem schließen und zukünftige Diskussionen/Probleme können im dotnet-test-nunit Repo weitergeführt werden.

Jetzt testen oder für immer schweigen :smile:

@rprouse : Ich habe nicht versucht, es auf Mono

Wird 69-CI einen Wirbel geben ...

Ein Unterschied, den ich zwischen diesem und dem Konsolen-App-Runner bemerkt habe, besteht darin, dass die "dotnet test" -Version die Zeit zu berücksichtigen scheint, die für das Finden von Tests in der Gesamtdauer aufgewendet wurde, während der "dotnet run" -Befehl, den ich mit NUnitLite verwendet habe, dies nicht tat . In Noda Time bedeutet dies, wenn ich mit --where=cat==Foo laufe (in dieser Kategorie gibt es keine solchen Tests), meldet "dotnet test" eine Dauer von 14s, während "dotnet run" eine Dauer von 0,01s meldet - trotz beide nehmen ungefähr die gleiche reale verstrichene Zeit.

Ist das beabsichtigt? Mir macht das Verhalten sicherlich nichts aus, aber es kann sich lohnen, es irgendwo zu erwähnen, um zu vermeiden, dass die Leute denken, es sei tatsächlich langsamer.

@jskeet das ist eine gute Beobachtung, es ist in der Tat der Fall. Da wir nicht über die vollständige NUnit-Engine verfügen, um die Tests auszuführen, ist der Code einfacher, aber ich kann die Uhr möglicherweise beim ersten Teststart-Ereignis starten, anstatt den Testlauf zu umschließen. Ich werde ein Problem eingeben.

Ich habe eine Alpha-Version von dotnet-test-nunit auf GitHub unter https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 veröffentlicht , sodass du deine Einstellungen nicht mehr ändern musst NuGet.config Datei und verwenden Sie CI-Releases.

Jetzt, da ich ein Alpha-Out habe, werde ich dieses Thema schließen. Bitte helfen Sie mir, die Alpha zu testen und alle Probleme unter https://github.com/nunit/dotnet-test-nunit/issues zu melden

Ich habe die Dokumentation in der Readme für dotnet-test-nunit aktualisiert. Ich werde das aktuell halten.

https://github.com/nunit/dotnet-test-nunit

Wie bereits erwähnt, müssen Sie die Laufzeiten nicht angeben, wenn Sie "type": "platform" für die Abhängigkeit "Microsoft.NETCore.App" . Angesichts der xUnit-Dokumentation denke ich, dass dies der bevorzugte Ansatz ist.

Ich habe derzeit eine Pull-Anfrage, die über Travis läuft - wenn das grün wird, hängt Noda Time davon ab, also sollte es _etwas_ Nutzung geben. Gut gemacht, Herr...

Ein Nachteil ist mir gerade aufgefallen - das bedeutet, dass ich mit Mono unter Linux nicht mehr ohne weiteres testen kann. Ich glaube, das ist kein NUnit-Problem, es ist im Grunde eine Manifestation von https://github.com/dotnet/cli/issues/3073, aber für NUnit. Ich hoffe immer noch, dass es irgendwann behoben werden könnte; vorerst werde ich meine Monotests in Travis mit etwas Widerwillen deaktivieren. ( dotnet test ist definitiv die Zukunft.)