Testgetriebene Entwicklung lernen

Kapitel 0: Einführung und Einrichtung

Ein blitzsauberer Code ist entscheidend für den Erfolg.

Ron Jeffries, "Clean Code: A Learning," Aug 23, 2017, ronjeffries.com

Bevor wir unsere Reise in die anspruchsvolle und lohnende Welt der testgetriebenen Entwicklung beginnen, müssen wir sicherstellen, dass wir eine funktionierende Entwicklungsumgebung haben. In diesem Kapitel geht es um die Vorbereitung und Einrichtung der Umgebung.

Einrichten deiner Entwicklungsumgebung

Unabhängig davon, welchen Lesepfad du wählst (siehe Abbildung P-2), brauchst du eine saubere Entwicklungsumgebung, um dieses Buch zu lesen. Im Rest des Buches wird davon ausgegangen, dass du die Entwicklungsumgebung wie in diesem Abschnitt beschrieben eingerichtet hast.

Wichtig

Unabhängig davon, ob du mit Go, JavaScript oder Python beginnst, richte deine Entwicklungsumgebung wie in diesem Abschnitt beschrieben ein.

Gemeinsame Einrichtung

Ordnerstruktur

Erstelle einen Ordner, der das Stammverzeichnis für den gesamten Quellcode sein wird, den wir in diesem Buch schreiben werden. Benenne ihn so, dass er auch in einigen Wochen noch klar und eindeutig ist, z. B. tdd-project.

Unter diesem Ordner erstellst du die folgenden Ordner:

tdd-project
├── go
├── js
└── py

Erstelle alle diese Ordner, bevor du die erste Codezeile schreibst, auch wenn du vorhast, dieses Buch in mehreren Durchgängen, eine Sprache nach der anderen, durchzuarbeiten. Das Anlegen dieser Ordnerstruktur bietet dir folgende Vorteile:

1. So bleibt der Code in den drei Sprachen getrennt und dennoch in unmittelbarer Nähe zueinander.

2. Damit wird sichergestellt, dass die meisten Befehle in diesem Buch ohne Änderungen funktionieren.

   • Befehle, die sich mit voll qualifizierten Datei-/Ordnernamen befassen, sind eine Ausnahme - und solche Befehle sind selten. Einer von ihnen ist in diesem Abschnitt zu finden.

3. Es ermöglicht die einfache Übernahme fortschrittlicher Funktionen, wie z.B. kontinuierliche Integration, in allen drei Sprachen.

4. Sie entspricht der Ordnerstruktur im zugehörigen Code-Repository. Das kann nützlich sein, um deinen Code zu vergleichen und zu vergleichen, während er sich weiterentwickelt.

Im weiteren Verlauf dieses Buches wird der Begriff TDD Project Root für den Stammordner verwendet, der den gesamten Quellcode enthält, der oben als tdd-project bezeichnet wurde. Die Ordner mit den Namen go, js und py werden mit diesen Namen bezeichnet - die Bedeutung ergibt sich aus dem Kontext.

Wichtig

TDD Project Root ist der Name für den Ordner, der den gesamten in diesem Buch entwickelten Quellcode enthält. Er ist der übergeordnete Ordner von drei Ordnern namens go, js und py.

Deklariere eine Umgebungsvariable mit dem Namen TDD_PROJECT_ROOT und setze ihren Wert auf den vollqualifizierten Namen des TDD-Projektstammordners. Wenn du dies einmal in jeder Shell tust (oder noch besser, einmal in deinem Shell-Initialisierungsskript, z. B. in der Datei .bashrc ), wird sichergestellt, dass alle nachfolgenden Befehle reibungslos funktionieren.

export TDD_PROJECT_ROOT=/fully/qualified/path/to/tdd-project

Auf meinem macOS-System lautet der vollständig qualifizierte Pfad für das TDD_PROJECT_ROOT beispielsweise /Users/saleemsiddiqui/code/github/saleem/tdd-project.

Abnehmen der Langeweile

Du musst die Umgebungsvariable TDD_PROJECT_ROOT in jeder neuen Shell, die du startest, definieren. Wenn dir das zu umständlich ist, kannst du sie einmalig in der entsprechenden Konfigurationsdatei setzen. Wie du sie setzt, ist von Betriebssystem zu Betriebssystem und von Shell zu Shell unterschiedlich. Für die Bash-ähnlichen Shells, die wir in diesem Buch verwenden werden, können Umgebungsvariablen in einer Konfigurationsdatei definiert werden; die Details variieren allerdings noch. Unter den meisten Linuxen (und unter macOS) kannst du zum Beispiel die Anweisung export TDD_PROJECT_ROOT=... in einer Datei namens .bashrc in deinem Home-Ordner hinzufügen. Wenn du Git BASH unter Windows verwendest - wie später in diesem Kapitel beschrieben -, musst du stattdessen die Datei .bash_profile verwenden.

Kurz gesagt: Es ist eine gute Sache, wenn du dir die Arbeit erleichtern kannst. Verwende einen geeigneten Mechanismus, um die Umgebungsvariablen zuverlässig und konsistent in allen Shells zu definieren, die du in diesem Buch verwendest.

Texteditor oder IDE

Wir brauchen einen Texteditor, um die Quelldateien zu bearbeiten. Eine integrierte Entwicklungsumgebung(IDE) kann helfen, indem sie ein einziges Tool bereitstellt, mit dem wir Code in mehreren Sprachen bearbeiten, kompilieren und testen können. Dies ist jedoch eine Frage der Wahl und der persönlichen Vorlieben; entscheide, was für dich am besten funktioniert.

In Anhang A werden IDEs genauer beschrieben.

Shell

Wir brauchen eine Shell - einen Kommandozeileninterpreter - um unsere Tests auszuführen, die Ausgabe zu untersuchen und andere Aufgaben zu erledigen. Wie bei den IDEs gibt es auch bei den Shells eine Vielzahl von Möglichkeiten, über die sich die Entwickler oft heftig streiten. In diesem Buch wird eine Bash-ähnliche Shell für die Befehle, die eingegeben werden müssen, vorausgesetzt. Auf den meisten - wenn auch nicht allen - Unix-ähnlichen Betriebssystemen (und auf macOS) ist eine Bash-Shell bereits verfügbar.

Für Windows gibt es Shells wie Git BASH. Unter Windows 10 bietet das Windows Subsystem für Linux native Unterstützung für die Bash-Shell, neben vielen anderen "Linux-Goodies". Eine dieser oder eine ähnliche Option ist ausreichend (und notwendig), um den Codebeispielen in diesem Buch zu folgen.

Abbildung 0-1 zeigt eine Bash-ähnliche Shell mit den Ergebnissen eines eingegebenen Befehls.

Abbildung 0-1. Eine Bash-ähnliche Shell, wie die hier gezeigte, wird benötigt, um die Programmierbeispiele in diesem Buch nachzuvollziehen

Git

Kapitel 13 führt in die Praxis der kontinuierlichen Integration (CI) mit GitHub-Aktionen ein. Um den Inhalten dieses Kapitels zu folgen, müssen wir ein eigenes GitHub-Projekt erstellen und Code dorthin pushen.

Git ist ein Open-Source-System zur verteilten Versionskontrolle. GitHub ist eine kollaborative Internet-Hosting-Plattform, die es Menschen ermöglicht, den Quellcode ihrer Projekte zu bewahren und mit anderen zu teilen.

Wichtig

Git ist ein freies, quelloffenes, verteiltes System zur Versionskontrolle. GitHub ist eine Code-Sharing-Plattform, die Git nutzt.

Um sicherzustellen, dass wir die kontinuierliche Integration einführen können, werden wir jetzt einige Vorbereitungen treffen und einige Arbeiten auf Kapitel 13 verschieben. Insbesondere werden wir die Versionskontrolle Git in unserer Entwicklungsumgebung einrichten. Das Anlegen eines GitHub-Projekts verschieben wir auf Kapitel 13.

Lade zuerst das System zur Versionskontrolle Git herunter und installiere es. Es ist für macOS, Windows und Linux/Unix verfügbar. Nachdem du es installiert hast, überprüfe, ob es funktioniert, indem du git --version in ein Terminalfenster eingibst und die Eingabetaste drückst. Als Antwort solltest du die installierte Version von Git sehen, wie in Abbildung 0-2 dargestellt.

Abbildung 0-2. Überprüfe, ob Git installiert ist, indem du git --version eingibst und die Eingabetaste drückst

Als Nächstes erstellen wir ein neues Git-Projekt in unserem TDD_PROJECT_ROOT. Gib in einem Shell-Fenster die folgenden Befehle ein:

cd $TDD_PROJECT_ROOT
git init .

Dies sollte zu einer Ausgabe führen, die lautet: Initialized empty Git repository in /your/fully/qualified/project/path/.git/. Dadurch wird ein neues (und derzeit leeres) Git-Repository in unserem TDD_PROJECT_ROOT angelegt. Wir sollten diese Ordner jetzt in unserem TDD-PROJECT-ROOT Ordner haben:

tdd-project
├── .git
├── go
├── js
└── py

Der Ordner .git wird von Git für die Buchführung verwendet. Es besteht keine Notwendigkeit, Änderungen an seinem Inhalt vorzunehmen.

Wenn wir in den folgenden Kapiteln Quellcode schreiben, werden wir unsere Änderungen regelmäßig in dieses Git-Repository übertragen. Dazu verwenden wir das Git CLI (Command Line Interface).

Wichtig

Im weiteren Verlauf dieses Buchs werden wir unsere Codeänderungen häufig an das Git-Repository übertragen. Um dies hervorzuheben, verwenden wir das Git-Symbol.

Geh

Um diesem Buch zu folgen, müssen wir Go Version 1.17 installieren. Diese Version ist für verschiedene Betriebssysteme zum Download verfügbar.

Um zu überprüfen, ob Go richtig installiert ist, gib in einer Shell go version ein und drücke Enter. Dies sollte die Versionsnummer deiner Go-Installation ausgeben. Siehe Abbildung 0-3.

Abbildung 0-3. Überprüfe, ob Go funktioniert, indem du in einer Shell go version eingibst und Enter drückst

Außerdem müssen wir ein paar Go-spezifische Umgebungsvariablen setzen:

1. Die Umgebungsvariable GO111MODULE sollte auf on gesetzt werden.

2. Die Umgebungsvariable GOPATH sollte nicht den Ordner TDD_PROJECT_ROOT oder darunter liegende Ordner wie den Ordner go enthalten.

Führe diese beiden Codezeilen in der Shell aus:

export GO111MODULE="on"
export GOPATH=""

Um Code schreiben zu können, müssen wir eine einfache go.mod Datei erstellen. Das sind die Befehle, die wir dafür brauchen:

cd $TDD_PROJECT_ROOT/go
go mod init tdd

Dadurch wird eine Datei namens go.mod erstellt, deren Inhalt sein sollte:

module tdd

go 1.17

Für alle Go-Entwicklungen ab diesem Zeitpunkt musst du sicherstellen, dass sich die Shell im Ordner go unter TDD_PROJECT_ROOT befindet.

Wichtig

Für den Go-Code in diesem Buch musst du zuerst cd $TDD_PROJECT_ROOT/go eingeben, bevor du einen Go-Befehl ausführst.

Ein kurzes Wort zur Go-Paketverwaltung

Die Paketverwaltung von Go befindet sich mitten in einem seismischen Wandel. Der alte Stil, bei dem die Umgebungsvariable GOPATH verwendet wurde, wird zugunsten des neueren Stils mit einer go.mod Datei abgeschafft. Die beiden Stile sind größtenteils nicht miteinander kompatibel.

Die beiden Umgebungsvariablen, die wir oben definiert haben, und die einfache go.mod Datei, die wir erstellt haben, stellen sicher, dass die Go-Tools korrekt mit unserem Quellcode arbeiten können, insbesondere wenn wir Pakete erstellen. Wir werden Go-Pakete in Kapitel 5 erstellen.

JavaScript

Wir brauchen Node.js v14 ("Fermium") oder v16, um diesem Buch zu folgen. Diese beiden Versionen sind auf der Node.js-Website für verschiedene Betriebssysteme erhältlich.

Um zu überprüfen, ob Node.js korrekt installiert ist, gibst du in einer Shell node -v ein und drückst die Eingabetaste. Der Befehl sollte eine einzeilige Meldung ausgeben, in der die Version von Node.js aufgeführt ist. Siehe Abbildung 0-4.

Abbildung 0-4. Überprüfe, ob Node.js funktioniert, indem du in einer Shell node -v eingibst und Enter drückst

Ein kurzes Wort zu Testbibliotheken

Es gibt mehrere Unit-Testing-Frameworks im Node.js Ökosystem. Im Großen und Ganzen sind sie hervorragend geeignet, um Tests zu schreiben und TDD durchzuführen. Dieses Buch verzichtet jedoch auf all diese Frameworks. Der Code verwendet das assert NPM-Paket für Assertions und eine einfache Klasse mit Methoden, um die Tests zu organisieren. Mit dieser Einfachheit wollen wir uns auf die Praxis und die Semantik von TDD konzentrieren und nicht auf die Syntax einer bestimmten Bibliothek. In Kapitel 6 wird die Organisation von Tests ausführlicher beschrieben. Anhang B listet die Test-Frameworks auf und nennt die Gründe, warum wir keines von ihnen verwenden.

Noch ein kurzes Wort zur JavaScript-Paketverwaltung

Ähnlich wie bei Test-Frameworks gibt es in JavaScript viele Möglichkeiten, Pakete und Abhängigkeiten zu definieren. In diesem Buch wird der CommonJS-Stil verwendet. In Kapitel 6 werden die anderen Stile besprochen: Der ES6- und der UMD-Stil werden ausführlich mit Quellcode dargestellt, der AMD-Stil eher kurz und ohne Quellcode.

Python

Wir brauchen Python 3.10, um diesem Buch zu folgen. Es ist auf der Python-Website für verschiedene Betriebssysteme erhältlich.

Die Sprache Python hat sich zwischen "Python 2" und "Python 3" stark verändert. Während eine ältere Version von Python 3 (z.B. 3.6) funktionieren kann, ist eine Version von Python 2 für die Zwecke dieses Buches ungeeignet.

Es ist möglich, dass du Python 2 bereits auf deinem Computer installiert hast. Zum Beispiel werden viele macOS-Betriebssysteme (einschließlich Big Sur) mit Python 2 ausgeliefert. Es ist nicht notwendig (und auch nicht empfehlenswert), Python 2 zu deinstallieren, um diesem Buch zu folgen; es ist jedoch notwendig, sicherzustellen, dass Python 3 die verwendete Version ist.

Um Mehrdeutigkeiten zu vermeiden, wird in diesem Buch python3 ausdrücklich als Name der ausführbaren Datei in den Befehlen verwendet. Es ist möglich - wenn auch unnötig -, den Befehl python mit einem "Alias" zu versehen, um auf Python 3 zu verweisen.

Hier ist eine einfache Methode, um herauszufinden, welchen Befehl du eingeben musst, um sicherzustellen, dass Python 3 verwendet wird. Gib python --version in einer Shell ein und drücke Enter. Wenn du etwas erhältst, das mit Python 3 beginnt, bist du in guter Verfassung. Wenn du etwas wie Python 2 erhältst, musst du für alle Befehle in diesem Buch explizit python3 eintippen.

Abbildung 0-5 zeigt eine Entwicklungsumgebung mit sowohl Python 2 als auch Python 3.

Abbildung 0-5. Überprüfe, ob Python 3 installiert ist und welchen Befehl du eingeben musst, um es zu benutzen (python3 wie hier gezeigt)

Wichtig

Verwende Python 3, um dem Code in diesem Buch zu folgen. Verwende nicht Python 2 - es wird nicht funktionieren.

Abbildung 0-6 zeigt eine Eselsbrücke zur Vereinfachung des vorangegangenen Python-Versions-Wirrwarrs!

Abbildung 0-6. Eine einfache Eselsbrücke, um zu verdeutlichen, welche Version von Python für dieses Buch benötigt wird!

Wo wir sind

In diesem einleitenden Kapitel haben wir uns mit der Toolchain vertraut gemacht, die wir brauchen, um unseren Code testgetrieben zu schreiben. Wir haben auch gelernt, wie wir unsere Entwicklungsumgebung vorbereiten und überprüfen, ob sie funktioniert.

Jetzt, wo wir wissen, worum es in diesem Buch geht, was darin steht, wie wir es lesen und vor allem, wie wir unsere Arbeitsumgebung einrichten, um es zu befolgen, sind wir bereit, unser Problem zu lösen, indem wir ein Feature nach dem anderen herausarbeiten, angetrieben durch Tests. Wir beginnen diese Reise in Kapitel 1. Los geht's!