C# xUnit Unit Test: So schreibst du deine ersten Unit Tests

Du hast gerade eine Methode geschrieben, sie einmal kurz mit `Console.WriteLine` ausprobiert und denkst: „Läuft." Dann fragt dein Ausbilder, dein Professor oder dein Teamlead: „Und was passiert bei negativen Zahlen? Bei 0? Bei sehr großen Werten?" - und plötzlich bist du nicht mehr so sicher. Genau für diese Momente gibt es Unit Tests: automatisch ausführbare Prüfungen, die deine Methode in Sekunden mit Dutzenden Fällen durchklopfen.

In diesem Artikel schreibst du deinen ersten C# xUnit Unit Test - und dafür baust du mit xUnit, dem beliebtesten Test-Framework für C#, ein komplettes Testprojekt von null auf. Am Ende führst du mit einem Befehl eine komplette Testsuite aus und siehst grüne Häkchen. Das Thema taucht übrigens in der IHK-Abschlussprüfung für Fachinformatiker auf, in Uni-Übungen und im Onboarding vieler Firmen - du investierst also in alle drei Lebenslagen gleichzeitig.

Was ist ein Unit Test?

Ein Unit Test prüft die kleinste eigenständig testbare Einheit deiner Software - in der Praxis fast immer eine einzelne Methode einer Klasse. Stell dir vor, du baust ein Auto: Bevor das fertige Auto zur Probefahrt rollt, testet jeder Zulieferer seine Bauteile einzeln. Der Airbag-Hersteller wartet nicht, bis das Auto crasht. Genauso testest du deine `Dividiere`-Methode isoliert, ohne die ganze Anwendung starten zu müssen.

Merke: Ein Unit Test prüft immer nur eine kleine, isolierte Einheit - typischerweise eine Methode. Er läuft automatisch, in Sekunden und ohne Datenbank, Netzwerk oder Benutzereingaben.

Voraussetzungen: Was brauchst du?

Du brauchst drei Dinge:

1. Das .NET SDK (am besten Version 8.0, das aktuelle LTS-Release) - kostenloser Download auf dotnet.microsoft.com

2. Einen Editor: Visual Studio (Windows) oder VS Code mit der C#-Erweiterung

3. Grundlagen in C#: Du solltest wissen, was Klassen, Methoden und Exceptions sind. Bei Exceptions hilft dir unser Beitrag zu C# Exception Handling weiter.

Außerdem benutzt du das dotnet CLI, also die Kommandozeile. Wenn du damit noch nicht vertraut bist, wirf einen Blick in unseren Artikel zu C# NuGet und dem dotnet CLI.

Schritt 1: Testprojekt anlegen

In C# liegen Tests immer in einem eigenen Projekt - getrennt vom Produktionscode. Warum? Weil die Test-Logik später nicht in deiner ausgelieferten Anwendung landen soll. Öffne ein Terminal und tippe:

mkdir TaschenrechnerDemo
cd TaschenrechnerDemo
dotnet new classlib -n RechnerLogik
dotnet new xunit -n RechnerLogik.Tests
cd RechnerLogik.Tests
dotnet add reference ../RechnerLogik/RechnerLogik.csproj

Was passiert hier? `dotnet new classlib` erstellt ein Klassenbibliotheks-Projekt für deinen Produktionscode. `dotnet new xunit` erzeugt ein Testprojekt, in dem xUnit bereits als NuGet-Paket installiert ist. Der letzte Befehl verknüpft beide Projekte mit einer Projektreferenz - ohne diese Referenz findet dein Testprojekt die Klassen nicht.

Lösche die Vorlagendateien `Class1.cs` (Bibliothek) und `UnitTest1.cs` (Testprojekt) - die brauchst du nicht.

Merke: Produktionscode und Testcode gehören in getrennte Projekte. Nur so stellst du sicher, dass Tests und Test-Pakete nicht mit deiner Anwendung ausgeliefert werden.

Schritt 2: Die Klasse schreiben, die du testen willst

Erstelle im Projekt `RechnerLogik` eine Datei `Taschenrechner.cs`:

namespace RechnerLogik;

public class Taschenrechner
{
  public int Addiere(int a, int b)
  {
    return a + b;
  }

  public int Dividiere(int a, int b)
  {
    if (b == 0)
    {
      throw new DivideByZeroException("Division durch 0 ist nicht erlaubt.");
    }
    return a / b;
  }
}

Zwei einfache Methoden - perfekt für den Einstieg. Die `Dividiere`-Methode wirft absichtlich eine Exception (einen Fehler), wenn jemand durch 0 teilt. Auch dieses Verhalten sicherst du gleich per Test ab.

Schritt 3: Dein erster Test mit [Fact]

Ein Unit Test in xUnit ist eine ganz normale Methode - markiert mit dem Attribut `[Fact]`. Erstelle im Testprojekt die Datei `TaschenrechnerTests.cs`:

using RechnerLogik;
using Xunit;

namespace RechnerLogik.Tests;

public class TaschenrechnerTests
{
  [Fact]
  public void Addiere_2Und3_Liefert5()
  {
    // Arrange: Alles vorbereiten
    var rechner = new Taschenrechner();

    // Act: Die zu testende Methode aufrufen
    int ergebnis = rechner.Addiere(2, 3);

    // Assert: Ergebnis pruefen
    Assert.Equal(5, ergebnis);
  }
}

Drei Dinge sind hier wichtig:

• `[Fact]` markiert die Methode als ausführbaren Test. Ohne dieses Attribut findet der Test Runner deine Methode nicht.

• Die Kommentare entsprechen dem AAA-Muster: Arrange (vorbereiten), Act (ausführen), Assert (prüfen). Dieses Muster begegnet dir in fast jedem Test-Tutorial und jeder Prüfung.

• `Assert.Equal` vergleicht erwarteten und tatsächlichen Wert. Die Reihenfolge ist immer: erst was du erwartest, dann was herauskommt.

Der Methodenname folgt einer gängigen Konvention: `Methode_Szenario_ErwartetesVerhalten`. Klingt sperrig, aber wenn der Test fehlschlägt, liest sich die Fehlermeldung wie ein Satz.

Schritt 4: Mehrere Testfälle mit [Theory] und [InlineData]

Ein `[Fact]` testet genau einen Fall. Willst du `Dividiere` mit mehreren Zahlenkombinationen prüfen, kombinierst du `[Theory]` mit `[InlineData]`:

[Theory]
[InlineData(10, 2, 5)]
[InlineData(9, 3, 3)]
[InlineData(-6, 2, -3)]
[InlineData(0, 5, 0)]
public void Dividiere_VerschiedeneEingaben_LiefertErwartetenWert(int a, int b, int erwartet)
{
  var rechner = new Taschenrechner();

  int ergebnis = rechner.Dividiere(a, b);

  Assert.Equal(erwartet, ergebnis);
}

Jede `[InlineData]`-Zeile ist ein eigener Testlauf mit anderen Parametern. Statt vier Methoden zu schreiben, hast du eine - und in der Übersicht siehst du trotzdem vier einzelne Ergebnisse. Das ist der Hauptunterschied zwischen den beiden Test-Typen:

Achtung, typische Falle: Beide Parameter sind `int` - und die Ganzzahldivision schneidet Nachkommastellen ab. `7 / 2` liefert also `3`, nicht `3.5`. Für Kommazahlen brauchst du `double`.

Und so testest du, dass eine Exception geworfen wird:

[Fact]
public void Dividiere_DurchNull_WirftException()
{
  var rechner = new Taschenrechner();

  Assert.Throws<DivideByZeroException>(() => rechner.Dividiere(5, 0));
}

Beachte den Pfeil `=>`: `Assert.Throws` braucht einen Lambda-Ausdruck, also einen Codeblock, der erst beim Aufrufen ausgeführt wird. Ohne das Lambda würde deine Methode schon vor dem Assert laufen und der Test crashen, statt sauber zu scheitern.

Schritt 5: Tests ausführen

Im Ordner des Testprojekts reicht ein einziger Befehl:

dotnet test

Du siehst eine Zusammenfassung wie `Passed! - Failed: 0, Passed: 5`. Herzlichen Glückwunsch, das sind deine ersten fünf grünen Unit Tests! Die offizielle Anleitung findest du bei Microsoft Learn, Details zu xUnit selbst auf xunit.net.

Wie sieht das komplette Projekt aus?

So ist dein Projekt am Ende strukturiert:

TaschenrechnerDemo/
├── RechnerLogik/
│   ├── RechnerLogik.csproj
│   └── Taschenrechner.cs
└── RechnerLogik.Tests/
    ├── RechnerLogik.Tests.csproj
    └── TaschenrechnerTests.cs

In `TaschenrechnerTests.cs` stehen alle drei Tests zusammen: der `[Fact]` für `Addiere`, die `[Theory]` mit vier `[InlineData]`-Fällen für `Dividiere` und der Exception-Test. Führe `dotnet test` aus und prüfe, ob alle fünf Tests grün sind.

Welche typischen Fehler passieren beim ersten Unit Test?

Problem 1: „Der Typ- oder Namespacename 'Taschenrechner' wurde nicht gefunden"

Deine Projektreferenz fehlt. Führe im Testprojekt-Ordner `dotnet add reference ../RechnerLogik/RechnerLogik.csproj` aus und danach einmal `dotnet build`.

Problem 2: Das Diff von Assert.Equal verwirrt dich

Häufig sind die Parameter vertauscht. Korrekt ist `Assert.Equal(erwartet, tatsaechlich)` - der erwartete Wert kommt immer zuerst. Bei vertauschter Reihenfolge läuft der Test trotzdem, aber die Fehlermeldung zeigt die Werte spiegelverkehrt.

Problem 3: Dein Test läuft einfach nicht mit

Meist fehlt das `[Fact]`- oder `[Theory]`-Attribut über der Methode. Außerdem findet der Test Runner nur kompilierte Tests - in VS Code also erst speichern, dann `dotnet build`, dann `dotnet test`.

FAQ: Häufige Fragen zu C# xUnit Unit Tests

Was ist der Unterschied zwischen [Fact] und [Theory]?

`[Fact]` markiert einen Test mit festen Werten und ohne Parameter. `[Theory]` markiert einen parametrisierten Test, der mit mehreren `[InlineData]`-Sets dieselbe Logik mit verschiedenen Eingaben prüft.

Was bedeutet AAA bei Unit Tests?

AAA steht für Arrange (Test vorbereiten), Act (Methode aufrufen) und Assert (Ergebnis prüfen). So bleibt jeder Test in drei klar getrennten Phasen strukturiert.

xUnit, NUnit oder MSTest - was soll ich lernen?

Für den Einstieg: xUnit. Es gilt als modernstes der drei Frameworks und wird in der Microsoft-Dokumentation bevorzugt. Die Konzepte - Asserts, Test Runner - sind bei allen dreien ähnlich, der Umstieg fällt später leicht. In Python heißt das Pendant übrigens pytest.

Wie viele Tests brauche ich pro Methode?

Mindestens einen pro öffentlicher Methode - plus Tests für Grenzfälle wie 0, negative Werte und erwartete Exceptions. Faustregel: Jede `if`-Verzweigung verdient einen eigenen Test.

Warum gehören Tests nicht ins Produktionsprojekt?

Weil Test-Code und Test-Pakete sonst mit deiner Anwendung ausgeliefert werden. Das bläht das Programm auf und kann im schlimmsten Fall Sicherheitslücken öffnen. Deshalb: immer ein separates Testprojekt.

Fazit: Von Hand testen war gestern

Du hast jetzt ein komplettes Testprojekt aufgebaut: Testprojekt angelegt, Projektreferenz gesetzt, Tests mit `[Fact]` und `[Theory]` geschrieben und alles per `dotnet test` ausgeführt. Genau dieses Wissen wird in der IHK-Prüfung, in Uni-Abgaben und im Berufsalltag erwartet - Unternehmen sehen Unit Tests nicht als optional, sondern als Grundvoraussetzung für sauberen Code. Mein Tipp: Bau die Beispiele nach und brich sie absichtlich. Nichts bringt dir C# xUnit Unit Tests näher als ein roter Test, den du selbst wieder grün machst.

Wenn du bei xUnit, C#-Grundlagen oder einem anderen Thema aus deiner Ausbildung oder deinem Studium festhängst: Bei study-it.education findest du persönliche Nachhilfe von Leuten, die wissen, wo Azubis, Studenten und Berufseinsteiger wirklich stolpern. Schau vorbei und mach aus roten Testfehlern grüne Häkchen.