16. Mär 2017
Lesedauer 6 Min.
Unit Tests mit .NET Core
.NET-Core-Anwendungen testen
Wie Sie mit den gängigen Unit-Test-Frameworks für .NET Core arbeiten.
Bild: Shutterstock / asharkyu
Microsofts neues Framework .NET Core wurde von Grund auf neu entwickelt. Ziel war ein leichtgewichtiges Framework, das nicht nur auf Windows, sondern auf allen wichtigen Plattformen läuft, also auch auf den am meisten verbreiteten Distributionen von Linux sowie auf dem Mac [1]. Inzwischen wurde .NET Core sogar auf Mini-Computern mit ARM-Prozessoren – wie beispielsweise dem Raspberry Pi – zum Laufen gebracht.
Das Schweizer Messer unter den Editoren
Visual Studio Code (kurz VS Code) ist nicht nur so umfangreich und flexibel wie das Schweizer „Sackmesser“, sondern es wird auch in der Schweiz – in Zürich – unter der Leitung von Erich Gamma entwickelt. VS Code basiert auf JavaScript und Node.js, wie GitHubs Editor Atom und Adobes Brackets auch. VS Code läuft daher sowohl unter MacOS als auch auf Linux und Windows. Mithilfe des OmniSharp-Projekts bietet VS Code eine umfangreiche C#-Unterstützung, ist aber auch ein beliebter Editor für die Web-Frontend-Entwicklung mit JavaScript, TypeScript sowie für die Backend-Entwicklung mit Node.js.
In diesem Artikel erfahren Sie, wie man Unit Tests für .NET Core erstellt. Dabei werden die Testwerkzeuge xUnit [2], NUnit [3] und MSTest [4] berücksichtigt. Zunächst wird die Nutzung von Visual Studio Code [5] – siehe Kasten Das Schweizer Messer unter den Editoren – und .NET CLI (siehe Kasten .NET CLI) gezeigt, um deutlich zu machen, wie .NET Core funktioniert. Der zweite Teil beschreibt die gleiche Arbeit unter Verwendung von Visual Studio 2017.
.NET CLI
Der .NET Core SDK enthält nicht nur den Support für Visual Studio, sondern auch ein Command Line Interface (CLI). Es ist die Grundlage für die Arbeit mit der Konsole, dem Terminal oder der Bash.
Unit Tests mit VS Code und .NET CLI
Mithilfe des .NET Command Line Interface (CLI) erstellen Sie als Beispielprojekt für diesen Artikel die neue Bibliothek namens SuperAwesomeLibrary sowie ein Test-Projekt dafür. Das klappt auf der Ebene der Konsole. Wechseln Sie dazu zunächst in das Arbeitsverzeichnis des Beispielprojekts und geben Sie dort die folgenden Befehle ein:mkdir SuperAwesomeLibrary
cd SuperAwesomeLibrary
dotnet new -t Lib
cd ..
mkdir SuperAwesomeLibrary.Tests
cd SuperAwesomeLibrary.Tests
dotnet new -t Xunittest
cd ..
code .
Das CLI erstellt daraufhin neue Bibliothek mit dem Namen SuperAwesomeLibrary und anschließend ein xUnit-Testprojekt namens SuperAwesomeLibrary.Tests. Alternativ passen Sie die Eingabezeile für NUnit oder für MSTest an.Im hier abgedruckten Beispiel wird weiterhin das Testing-Tool xUnit benutzt: dotnet new -t Xunittest. Die letzte Zeile des obigen Codes – code . – öffnet das aktuelle Arbeitsverzeichnis in VS Code (Bild 1).
Jetzt fehlt im Testprojekt noch eine Referenz auf das zu testende Projekt. Dafür genügt ein weiteres Kommando in der bereits geöffneten Konsole:
cd SuperAwesomeLibrary.Tests
dotnet add p2p
..\SuperAwesomeLibrary\
SuperAwesomeLibrary.csproj
Das Kommando dotnet add fügt Elemente zur Projektdatei hinzu. Aktuell steht dafür nur p2p zur Verfügung, das für Project-2-Project steht. Es wird also eine Referenz auf das zu testende Projekt angelegt.Anschließend rufen Sie dotnet restore und dotnet build auf, um alle NuGet-Pakete zu laden und einen ersten Build-Lauf auszuprobieren. Durch die jetzt vorhandene Referenz wird das abhängige Projekt mitberücksichtigt.
Listing 1: Die zu testende Klasse
public class MathTools
{
public decimal Add(decimal a, decimal b)
{
return a + b;
}
public decimal Substr(decimal a, decimal b)
{
return a - b;
}
public decimal Multiply(decimal a, decimal b)
{
return a * b;
}
public decimal Divide(decimal a, decimal b)
{
return a / b;
}
}
Um etwas zum Testen zu haben, sollten Sie eine zu testende Klasse anlegen, die auch etwas tut. Im Beispiel ist es die Klasse MathTools, welche Hilfsfunktionen für die vier Grundrechenarten bereitstellt, siehe Listing 1. Zum Erstellen und Bearbeiten der Klasse kommt VS Code zum Einsatz.Ist die Klasse angelegt, wechseln Sie in der Konsole zum Projektverzeichnis und rufen das Kommando dotnet build auf. Der Build sollte fehlerfrei durchlaufen.Die erstellte Klasse kann nun mit der passenden Unit-Testklasse im Unit-Testprojekt getestet werden (Listing 2).
Listing 2: xUnit Test
public class MathToolsTests
{
[Fact]
public void AddTest()
{
var sut = new MathTools();
var result = sut.Add(1M, 2M);
Assert.True(3M == result);
}
[Fact]
public void SubstrTest()
{
var sut = new MathTools();
var result = sut.Substr(2M, 1M);
Assert.True(1M == result);
}
[Fact]
public void MultiplyTest()
{
var sut = new MathTools();
var result = sut.Multiply(2M, 1M);
Assert.True(2M == result);
}
[Fact]
public void DivideTest()
{
var sut = new MathTools();
var result = sut.Divide(2M, 2M);
Assert.True(1M == result);
}
}
In VS Code sollten keine Fehler zu sehen sein. Ist alles in Ordnung, wechseln Sie per Konsole ins Verzeichnis des Testprojekts und rufen auch dort dotnet build auf.
Beide Projekte sollten fehlerfrei aufgebaut werden. Durch die Referenz auf das zu testende Projekt werden wieder beide Projekte gebaut (Bild 2). Ist der Build-Prozess abgeschlossen, können Sie den Test via Konsole mittels dotnet test aufrufen, siehe Bild 3.
Dieses Kommando ruft den xUnit-Testrunner auf, der als NuGet-Paket eingebunden wurde. Dieser wiederum führt die Test-DLL aus. Das Kommando dotnet test kann später in jedem Continuous-Integration-Werkzeug ausgeführt werden, um das Ergebnis automatisch auszuwerten. Bei Bedarf werden beide Projekte vorher gebaut.
Unit Tests in Visual Studio 2017
Eine Notiz vorab: Es kann sein, dass das Tool ReSharper mit .NET-Core-Projekten nicht ganz zurechtkommt. Daher empfiehlt es sich, ReSharper für .NET-Core-Projekte temporär abzuschalten. Der Testrunner von ReSharper ist bis dato ebenfalls nicht in der Lage, .NET-Core-Tests sauber auszuführen.Öffnen Sie nun das zuvor per CLI erstellte Projekt mit Visual Studio und fügen Sie anschließend das Testprojekt zur Solution hinzu. Die von Visual Studio angelegte Solution-Datei können Sie ignorieren oder einfach in dem Ordner ablegen, in dem auch die beiden Projektordner liegen. Visual Studio sollte anschließend die beiden Beispielprojekte im Projektmappen-Explorer anzeigen (Bild 4).
Ist alles gespeichert, lassen sich die Projekte wie gewohnt mit Visual Studio aufbauen. Wie sieht es aber im Test-Explorer von Visual Studio aus? Öffnen Sie den Test-Explorer über das Menü Tests | Windows | Test-Explorer. Bild 5 zeigt den Test-Explorer mit den geladenen Tests.
Die Tests starten Sie nun entweder per Mausklick auf Run All oder mit der Tastenkombination [Ctrl]+[R]+[A]. Wie Sie in Bild 6 sehen, führt Visual Studio alle Tests wie gewohnt aus. Selbst das Debuggen von Tests ist kein Problem.
Darüber hinaus erlaubt Visual Studio auch das Anlegen neuer Testprojekte. Als Beispiel wird ein MSTest-Projekt zur bestehenden Solution hinzugefügt. Im Projektauswahldialog wählen Sie dazu den Eintrag Unit Test Project (.NET Core) (Bild 7).
Als Namen für das neue Projekt könnten Sie zum Beispiel SuperAwesomeLibrary.MSTest wählen. Auf die bekannte Weise setzen Sie wieder eine Referenz auf das zu testende Projekt. Anschließend wird die vorhandene Testklasse zum neuen Testprojekt hinzugefügt und an MSTest angepasst, siehe Listing 3.Nach erfolgreichem Build sind die Tests beider Test-Frameworks im Test-Explorer sichtbar und können auch gemeinsam ausgeführt werden.
Listing 3: MSTest
[TestClass]
public class MathToolsTests
{
[TestMethod]
public void AddTest()
{
var sut = new MathTools();
var result = sut.Add(1M, 2M);
Assert.IsTrue(3M == result);
}
[TestMethod]
public void SubstrTest()
{
var sut = new MathTools();
var result = sut.Substr(2M, 1M);
Assert.IsTrue(1M == result);
}
[TestMethod]
public void MultiplyTest()
{
var sut = new MathTools();
var result = sut.Multiply(2M, 1M);
Assert.IsTrue(2M == result);
}
[TestMethod]
public void DivideTest()
{
var sut = new MathTools();
var result = sut.Divide(2M, 2M);
Assert.IsTrue(1M == result);
}
} Continuous Integration
Für Continuous-Integration-Szenarien empfiehlt es sich, das .NET Core CLI zu nutzen. Nach dem Pull, Check-Out beziehungsweise dem Update der Sourcen wechseln Sie per Batch-Ausführung ins Projektverzeichnis des Testprojekts und führen folgende Kommandos aus:
dotnet restore
dotnet test –logger:trx
Der zweite Befehl schreibt die Resultate in eine Visual-Studio-Testresult-Datei mit der Endung *.trx. Diese Dateien können mit Visual Studio und dem Team Foundation Server (TFS) eingelesen werden. Eventuell bieten andere Build-Server ebenfalls eine Möglichkeit, diese Dateien einzulesen, um daraus Testberichte zu erstellen. Über das Argument -logger lassen sich beliebige Logger einbinden. Der TRX Logger steht als Standard zur Verfügung.
Fazit
Das Anlegen von Unit Tests für .NET-Core-Anwendungen klappt mit .NET Core CLI und Visual Studio 2017 einfach und schnell. Das Command Line Interface erlaubt es, Unit Tests auf allen wichtigen Plattformen (Windows, Linux und Mac) anzulegen. Visual Studio stellt den gewohnten Komfort beim Erstellen von Tests bereit.Das einzige Manko der aktuellen SDK-Version für Visual Studio 2017 ist, dass man bei ASP.NET-Projekten nicht gleich ein Unit-Test-Projekt mit anlegen kann. Aber das könnte sich in zukünftigen Versionen noch ändern.Fussnoten
- .NET-Core-Webseite, https://dotnet.microsoft.com/en-us/download
- xUnit,
- NUnit, https://nunit.org/
- MSTest,
- VS Code, https://code.visualstudio.com
