TDD in C#: Hör auf, Angst vor Tests zu haben und schreibe Code, den du zeigen kannst

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Warum "Tests zuerst" kein Masochismus, sondern eine Superkraft ist

\n\n

Stellen Sie sich vor: Sie schreiben Code, alles funktioniert. Sie sind glücklich. Einen Monat später kehren Sie zum Projekt zurück, ändern eine Zeile – und alles bricht zusammen. Kommt Ihnen das bekannt vor? Willkommen im Club der Entwickler, die keine Tests schreiben. Stellen Sie sich nun eine andere Realität vor: Sie ändern Code, führen Tests aus – und wissen nach 10 Sekunden, dass nichts kaputtgegangen ist. Das ist keine Magie, das ist TDD (Test-Driven Development) – testgetriebene Entwicklung.

\n\n

In diesem Artikel analysieren wir TDD am Beispiel von C#. Ohne langweilige Theorie. Nur Praxis, Code und reale Anwendungsfälle. Wenn Sie denken, TDD sei nur für "reine Architekten" oder "Enterprise-Monster" – Sie werden überrascht sein. Es ist ein Werkzeug, das Ihren Code und Ihre Nerven rettet.

\n\n

Was ist TDD und wie funktioniert Red-Green-Refactor

\n\n

TDD geht nicht ums Testen. Es geht um Design. Sie schreiben Tests nicht nach dem Code, sondern umgekehrt: zuerst der Test, dann der minimale Code, der ihn besteht, und erst dann das Refactoring. Dieser Zyklus heißt Red-Green-Refactor:

\n\n

Red – wir schreiben einen Test, der bewusst fehlschlägt (rot).
Green – wir schreiben minimalen Code, damit der Test bestanden wird (grün).
Refactor – wir verbessern den Code, ohne sein Verhalten zu ändern.

\n\n

Kommt Ihnen das seltsam vor? Sehen wir es uns an einem Beispiel an. Angenommen, wir brauchen einen Taschenrechner mit einer Additionsmethode. Normalerweise schreiben wir zuerst die Klasse, dann den Test. Bei TDD ist es umgekehrt.

\n\n

Schritt 1: Red – wir schreiben einen Test, der fehlschlägt

\n\n

using NUnit.Framework;\n\n[TestFixture]\npublic class CalculatorTests\n{\n    [Test]\n    public void Add_ShouldReturnSumOfTwoNumbers()\n    {\n        // Arrange\n        var calculator = new Calculator();\n        \n        // Act\n        var result = calculator.Add(2, 3);\n        \n        // Assert\n        Assert.AreEqual(5, result);\n    }\n}

\n\n

Wir führen ihn aus – der Test schlägt fehl, weil die Klasse Calculator nicht existiert. Rot ist normal. Jetzt ist unsere Aufgabe, Grün zu erreichen.

\n\n

Schritt 2: Green – minimaler Code, damit der Test bestanden wird

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        return a + b; // Minimale Implementierung\n    }\n}

\n\n

Der Test ist grün. Hurra. Aber der Code ist noch hässlich. Weiter zu Schritt 3.

\n\n

Schritt 3: Refactor – verbessern, ohne zu zerstören

\n\n

In dieser Phase können wir Prüfungen, Ausnahmebehandlung hinzufügen oder die Architektur ändern. Hauptsache, die Tests bleiben grün.

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        if (a < 0 || b < 0)\n            throw new ArgumentException("Only positive numbers allowed");\n        return a + b;\n    }\n}

\n\n

Wird der Test fehlschlagen? Ja. Also müssen wir den Test aktualisieren oder die Logik ändern. Bei TDD ist Refactoring immer ein Dialog mit den Tests.

\n\n