chapters: Fliesstext auf 57 reine Textseiten kuerzen

Zwei Kompressionsdurchgaenge ueber Kapitel 2-7. Entfernt wurden
Redundanzen, Meta-Kommentare, Ueberklaerungen und Fuellsaetze;
Fakten, Namen, Daten, Entscheidungen samt Begruendung sowie alle
Abbildungen und Tabellen bleiben unveraendert.

Reine Textseiten: 78 -> 57 (Woerter 19613 -> 12451).
Gesamt-PDF: 138 -> 116 Seiten.

chapters/qa/unit-tests.tex

@@ -3,30 +3,26 @@
 
 \subsection{Testbarkeit durch Kapselung}
 
-Die Voraussetzung für die Testbarkeit des Moduls wurde bereits mit dem Entwurf geschaffen. Da der Speicherzugriff ausschließlich über die Schnittstelle des SDK erfolgt, lässt sich diese in Tests durch eine Attrappe ersetzen. Die Tests laufen damit ohne Netzwerkverbindung, ohne Zugangsdaten und ohne einen realen Speicher.
+Da der Speicherzugriff über die SDK-Schnittstelle erfolgt, lässt sich diese in Tests durch eine Attrappe ersetzen. Die Tests laufen damit ohne Netzwerkverbindung, ohne Zugangsdaten und ohne einen realen Speicher.
 
-Dies ist mehr als eine Bequemlichkeit. Erst die Attrappe erlaubt es, Zustände herzustellen, die sich real kaum oder nur mit erheblichem Aufwand erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne jedes Metadatum. Genau diese Randfälle sind es, die in der Praxis selten auftreten und deren Behandlung deshalb ohne Test unbemerkt fehlerhaft bleiben könnte.
+Die Attrappe erlaubt Zustände, die sich real kaum erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne Metadatum. Gerade diese Randfälle könnten ohne Test unbemerkt fehlerhaft bleiben.
 
 \subsection{Abgedeckte Pfade}
 
-Die Tests des Kundenordner-Lookups bilden die in Abschnitt~\ref{sec:lookup-decision} beschriebenen Wege einzeln ab: den Direktzugriff bei korrektem Ordnernamen, den Kollisionsfall, die Rückfallebene mit anschließender Umbenennung, das Anlegen eines fehlenden Kundenordners sowie das Ignorieren eines Ordners ohne gültiges Metadatum. Für jeden Weg wird nicht nur das Ergebnis geprüft, sondern auch, welche Zugriffe auf den Speicher tatsächlich erfolgt sind — beim Direktzugriff etwa, dass genau eine Metadatenabfrage und keine Auflistung stattgefunden hat.
+Die Tests bilden die in Abschnitt~\ref{sec:lookup-decision} beschriebenen Wege einzeln ab: Direktzugriff, Kollisionsfall, Rückfallebene mit Umbenennung, Anlegen eines fehlenden Kundenordners und Ignorieren eines Ordners ohne gültiges Metadatum. Geprüft wird nicht nur das Ergebnis, sondern auch die Speicherzugriffe — beim Direktzugriff etwa, dass genau eine Metadatenabfrage und keine Auflistung stattfand.
 
-Dieser Punkt verdient Beachtung: Die Anforderung an den Lookup war keine funktionale, sondern eine über den Aufwand. Ein Test, der lediglich das richtige Präfix prüft, würde auch dann bestehen, wenn die Implementierung weiterhin alle Ordner durchliefe. Die eigentliche Eigenschaft — dass der Regelfall mit einem einzigen Zugriff auskommt — lässt sich nur über die beobachteten Aufrufe der Attrappe prüfen.
+Die Anforderung an den Lookup war keine funktionale, sondern eine über den Aufwand. Ein Test, der nur das richtige Präfix prüft, bestünde auch, wenn die Implementierung weiterhin alle Ordner durchliefe. Die eigentliche Eigenschaft — dass der Regelfall mit einem einzigen Zugriff auskommt — lässt sich nur über die beobachteten Aufrufe prüfen.
 
 \subsection{Testdaten}
 
-Ein Reviewfund betraf die verwendeten Testdaten. \emph{Timo Walter} merkte an, dass in den Tests reale Kundennamen verwendet wurden, und schlug Platzhalter vor.
-
-Der Hinweis ist inhaltlich klein, in der Sache aber richtig. Testdaten sind Quelltext: Sie liegen in der Versionsverwaltung, sind für jeden mit Zugriff auf das Repository lesbar und bleiben dort dauerhaft erhalten, auch wenn sie später geändert werden. Ein realer Kundenname in einem Testfall stellt damit eine unnötige Offenlegung dar — unnötig deshalb, weil der Test mit einem Platzhalternamen exakt denselben Zweck erfüllt. Die Testdaten wurden entsprechend ersetzt.
+\emph{Timo Walter} merkte an, dass reale Kundennamen in den Tests verwendet wurden, und schlug Platzhalter vor. Der Hinweis ist klein, in der Sache aber richtig: Testdaten liegen in der Versionsverwaltung und bleiben dauerhaft lesbar; ein realer Kundenname ist eine unnötige Offenlegung, da der Test mit Platzhaltern denselben Zweck erfüllt. Die Daten wurden ersetzt.
 
 \subsection{Ein Test, der das Falsche prüfte}
 
-Der aufschlussreichste Fund der gesamten Qualitätssicherung betraf einen Test, der bestand — aber aus dem falschen Grund. \emph{Timo Walter} bemerkte beim Lesen, dass der Prüfling bereits in der ersten Zeile abbrach, weil die Auswertung des Pfades einen unbekannten Typbezeichner vorfand und daraufhin kein Ergebnis lieferte. Der Test endete damit, bevor die eigentlich zu prüfende Logik überhaupt erreicht war.
+\emph{Timo Walter} bemerkte beim Lesen, dass ein Test bestand, aber aus dem falschen Grund: Der Prüfling brach in der ersten Zeile ab, weil die Pfadauswertung einen unbekannten Typbezeichner vorfand — die eigentlich zu prüfende Logik wurde nie erreicht.
 
-Aus dieser Beobachtung leitete er zusätzlich einen vermuteten Fehler im Code ab: Ein Dokument, das unmittelbar im Kundenordner liegt und damit keinen Typ trägt, dürfe nicht dazu führen, dass die Auswertung scheitert.
+Er leitete einen vermuteten Fehler ab: Ein Dokument ohne Typ dürfe die Auswertung nicht scheitern lassen. Die Klärung ergab, dass der Code korrekt, der Test aber missverständlich benannt war. Geprüft wurde eine Sicherheitseigenschaft: dass ein Benutzer, der den Kundennamen als Pfadbestandteil in die Adresse schreibt, kein Ergebnis erhält und keine Anfrage an den Speicher ausgelöst wird.
 
-Die anschließende Klärung ergab, dass der Code korrekt war, der Test jedoch missverständlich benannt und aufgebaut. Geprüft wurde nämlich nicht der untypisierte Fall, sondern eine Sicherheitseigenschaft: dass ein Benutzer, der den Kundennamen selbst als Pfadbestandteil in die Adresse schreibt, kein Ergebnis erhält und dass daraufhin keine Anfrage an den Speicher abgesetzt wird. Der Kundenname darf im relativen Pfad niemals vorkommen — genau das war der Gegenstand des Tests.
+Der Vorgang zeigt zweierlei: Ein Test, der aus dem falschen Grund grün ist, ist wertlos, weil er Sicherheit suggeriert. Der Fund war nicht durch Ausführen zu erzielen, sondern nur durch Lesen — er belegt den Wert des Reviews für Testcode.
 
-Der Vorgang ist in zweifacher Hinsicht lehrreich. Zum einen zeigt er, dass ein bestandener Test keine Aussage über die geprüfte Eigenschaft trifft, solange nicht sichergestellt ist, dass er den relevanten Codepfad überhaupt erreicht — ein Test, der aus dem falschen Grund grün ist, ist wertlos und zugleich gefährlich, weil er Sicherheit suggeriert. Zum anderen zeigt er den Wert des Reviews für Testcode: Der Fund war nicht durch Ausführen zu erzielen, sondern nur durch Lesen.
-
-Als Konsequenz wurde die Absicht des Tests explizit gemacht. Genau diese Anforderung — dass ein Test ohne den zugehörigen Fix fehlschlagen muss — wurde später auch in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (siehe Abschnitt~\ref{sec:race-conditions}).
+Als Konsequenz wurde die Absicht des Tests explizit gemacht. Diese Anforderung — dass ein Test ohne den Fix fehlschlagen muss — wurde in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (siehe Abschnitt~\ref{sec:race-conditions}).