Test Driven Development (TDD) ist eine Softwareentwicklungsmethode, bei der der Entwicklungsprozess auf das Schreiben von Tests vor der Implementierung des eigentlichen Codes ausgerichtet ist. Es folgt einem einfachen Zyklus, der aus drei Hauptphasen besteht. In diesem Blog-Artikel möchte ich die drei Stages des Test Driven Development (TDD) nach Robert C. Martin, auch bekannt als Uncle Bob, näher erläutern: die rote Kappe, die grüne Kappe und die blaue Kappe.
(Die Analogie der farbigen Kappen hilft Entwicklern, den TDD-Prozess besser zu verstehen und die verschiedenen Phasen zu visualisieren. Es betont die Idee, dass TDD ein iterativer Prozess ist, bei dem Tests und Codeentwicklung eng miteinander verflochten sind, um hochwertige Software zu erstellen. So beschreibt Robert C. Martin den Prozess des TDD. )

• Rote Kappe (Red Phase): In dieser Phase wird zuerst ein Testfall geschrieben, der die erwartete Funktionalität des zu entwickelnden Codes beschreibt. Der Test wird absichtlich so geschrieben, dass er fehlschlägt, da der Code noch nicht implementiert wurde.
• Grüne Kappe (Green Phase): Hier wird der eigentliche Code entwickelt, um den Testfall zum Bestehen zu bringen. Das Hauptziel besteht darin, nur den minimalen Code zu schreiben, um den Test erfolgreich zu machen, ohne zusätzliche Funktionalität hinzuzufügen.
• Blaue Kappe (Blue Phase): In dieser Phase erfolgt das Refactoring des Codes, um sicherzustellen, dass er sauber, wartbar und effizient ist. Es wird kein neuer Funktionscode hinzugefügt, sondern der vorhandene Code wird verbessert.

Dieser Zyklus wird immer wieder wiederholt: Test schreiben, Test bestehen lassen und Code refaktorisieren. Durch diese iterative Vorgehensweise wird sichergestellt, dass der Code immer gut getestet ist und Änderungen oder Erweiterungen am Code keine unerwünschten Nebenwirkungen haben.

TDD hilft Entwicklern, qualitativ hochwertigen Code zu schreiben, da es die Testabdeckung sicherstellt und frühzeitig Probleme erkennt. Es fördert auch das Design von Software, da Entwickler die Anforderungen in kleine, testbare Teile aufteilen müssen. TDD ist ein wichtiger Bestandteil von agilen Entwicklungsmethoden und hat sich als effektive Methode zur Verbesserung der Codequalität und der Entwicklungsproduktivität erwiesen.

1. "Rote Kappe": Test schreiben

Die erste Phase, die "rote Kappe", ist der Ausgangspunkt. Hier schreibe ich den Test, bevor ich irgendeinen Code schreibe. Dieser Test sollte fehlschlagen, da der zugehörige Code noch nicht existiert. Das Beispiel in PHP sieht so aus:

public function testAddition()
{
    $calculator = new Calculator();
    $result = $calculator->add(2, 3);
    $this->assertEquals(5, $result);
}

2. "Grüne Kappe": Code schreiben

Nachdem der Test in der roten Kappe fehlgeschlagen ist, schreibe ich den minimalen Code, um den Test zum Bestehen zu bringen. Dabei ist das Ziel, den Test in der "grünen Kappe" erfolgreich durchzuführen:

class Calculator
{
    public function add($a, $b)
    {
        return $a + $b;
    }
}

3. "Blaue Kappe": Refactoring

In der letzten Phase, der "blauen Kappe", nehme ich mir Zeit, um den Code zu optimieren und zu verbessern, ohne die Funktionalität zu ändern. Refactoring ist entscheidend, um sauberen und wartbaren Code zu erhalten:

class Calculator
{
    public function add(int $a, int $b): int
    {
        return $a + $b;
    }
}

Tipps für effektives TDD:

• Starte immer mit einem klaren Ziel für deinen Test.
• Schreibe den einfachsten Testfall zuerst.
• Erweitere den Code nur, um den aktuellen Testfall zu bestehen.
• Refactoring sollte regelmäßig erfolgen, um die Codequalität zu erhöhen.
• Verwende ein Tool wie PHPUnit, um deine Tests automatisch auszuführen.

Clean Code ist von Robert Cecil Martin definiert und revolutioniert die Art und Weise, wie wir programmieren. Es geht darum, Code verständlich, effizient und leicht wartbar zu gestalten. Hier sind einige Tipps in PHP, um Clean Code zu schreiben.
Natürlich, Flexibilität ist wichtig, besonders wenn sich die Anforderungen ändern, daher sind diese Regel eher als Richtlinien zu verstehen, als wie in Stein gemeißelte Gebote. Es ist jedoch eine gute Praxis, bei jedem Schritt des Programmierens sorgfältig über jede Zeile Code nachzudenken, nicht nur bei neuen Projekten. Dies gewährleistet Konsistenz und Qualität in deinem Code.

Warum ist Clean Code wichtig?

Sauberen Code zu schreiben, ist entscheidend, weil er:

• Die Lesbarkeit verbessert: Anderen Entwicklern und dir selbst fällt es leichter, den Code zu verstehen und zu warten.
• Fehler leichter identifizieren lässt: Fehler sind schneller gefunden und behoben, da der Code logischer strukturiert ist.
• Die Zusammenarbeit erleichtert: Wenn du in einem Team arbeitest, wird sauberer Code zu einer gemeinsamen Sprache, die alle verstehen können.
• Die Skalierbarkeit erhöht: Es wird einfacher, neue Funktionen hinzuzufügen, ohne den gesamten Code zu überarbeiten.
  
  

Zusammenfassung des Buches

Allgemeine Regeln

• Folge den Standardkonventionen.
• Einfachheit ist besser. Reduziere die Komplexität so weit wie möglich.
• Pflege die Boy-Scout-Regel. Verlasse den Ort sauberer als du ihn vorgefunden hast.
• Finde immer die Wurzelursache. Suche immer nach der Wurzelursache eines Problems.

Designregeln

• Halte konfigurierbare Daten auf hohen Ebenen (config Dateien).
• Bevorzuge Polymorphismus gegenüber if/else oder switch/case.
• Trenne den Mehrfaden-Code.
• Vermeide übermäßige Konfigurierbarkeit.
• Verwende Dependency Injection.
• Befolge das Gesetz von Demeter. Eine Klasse sollte nur ihre direkten Abhängigkeiten kennen.

Tipps zur Verständlichkeit

• Sei konsistent. Wenn du etwas auf eine bestimmte Weise machst, tue alle ähnlichen Dinge auf die gleiche Weise.
• Verwende erklärende Variablen.
• Kapsle Randbedingungen ein. Randbedingungen sind schwer nachzuverfolgen. Platziere die Verarbeitung für sie an einer Stelle.
• Bevorzuge dedizierte Wertobjekte gegenüber primitiven Typen.
• Vermeide logische Abhängigkeiten. Schreibe keine Methoden, die je nach etwas anderem in derselben Klasse korrekt funktionieren.

Namensregeln

• Wähle beschreibende und eindeutige Namen.
• Mache sinnvolle Unterscheidungen.
• Verwende aussprechbare Namen.
• Verwende durchsuchbare Namen.
• Ersetze magische Zahlen durch benannte Konstanten.
• Vermeide Codierungen. Hänge keine Präfixe oder Typinformationen an.

Regeln für Funktionen

• Klein.
• Machen genau eine Sache.
• Verwende aussagekräftige Namen.
• Bevorzuge weniger Argumente.
• Habe keine Seiteneffekte.
• Verwende keine Flaggenargumente. Teile die Methode in mehrere unabhängige Methoden auf, die vom Client ohne Flagge aufgerufen werden können.

Regeln für Kommentare

• Versuche immer, dich im Code zu erklären.
• Sei nicht redundant.
• Füge keine offensichtlichen Störungen hinzu.
• Verwende keine schließenden Kommentare in Klammern.
• Kommentiere keinen Code aus. Entferne ihn einfach.
• Verwende Kommentare zur Erläuterung der Absicht.
• Verwende Kommentare zur Klarstellung des Codes.
• Verwende Kommentare zur Warnung vor Konsequenzen.

Struktur des Quellcodes

• Trenne Konzepte vertikal.
• Zusammenhängender Code sollte vertikal dicht erscheinen.
• Deklariere Variablen in der Nähe ihrer Verwendung.
• Abhängige Funktionen sollten nah beieinander liegen.
• Ähnliche Funktionen sollten nah beieinander liegen.
• Platziere Funktionen in absteigender Richtung.
• Halte Zeilen kurz.
• Verwende keine horizontale Ausrichtung.
• Verwende Leerzeichen, um zusammengehörige Dinge zu verknüpfen und schwach zusammenhängende zu trennen.
• Breche die Einrückung nicht.

Objekte und Datenstrukturen

• Verberge die interne Struktur.
• Bevorzuge Datenstrukturen.
• Vermeide hybride Strukturen (halb Objekt und halb Daten).
• Sollte klein sein.
• Mache eine Sache.
• Kleine Anzahl von Instanzvariablen.
• Die Basisklasse sollte nichts über ihre Ableitungen wissen.
• Besser viele Funktionen als Code in eine Funktion übergeben, um ein Verhalten auszuwählen.
• Bevorzuge nicht-statische Methoden gegenüber statischen Methoden.

Tests

• Ein Assert pro Test.
• Lesbar.
• Schnell (tests sollten extrem schnell sein, dann entwickelt man lieber).
• Unabhängig.
• Wiederholbar.

Codegerüche

• Starrheit. Die Software ist schwer zu ändern. Eine kleine Änderung verursacht eine Kaskade von nachfolgenden Änderungen.
• Zerbrechlichkeit. Die Software bricht an vielen Stellen aufgrund einer einzelnen Änderung.
• Immobilität. Teile des Codes können aufgrund von Risiken und hohem Aufwand nicht in anderen Projekten wiederverwendet werden.
• Unnötige Komplexität.
• Unnötige Wiederholung.
• Undurchsichtigkeit. Der Code ist schwer zu verstehen.
  
  

Alle Funktionen, Methoden, Variablen, Ordner und Dateinamen sollten so benannt werden, dass der Code selbst wie ein gut verständliches Gedicht wirkt und Kommentare überflüssig werden. Abschließend, erinnere dich immer daran, dass Clean Code nicht nur eine Technik, sondern eine Denkweise ist. Es lohnt sich, in diese Fähigkeiten zu investieren, um zu einem besseren Entwickler zu werden.
Mehr Informationen: WIKIPEDIA