Textreduktion

chapters/qa/unit-tests.tex

@@ -3,18 +3,12 @@
 
 \subsection{Testbarkeit durch Kapselung}
 
-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.
-
-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.
+Da der Speicherzugriff über die SDK-Schnittstelle erfolgt, lässt sich diese in Tests durch eine Attrappe ersetzen; die Tests laufen ohne Netzwerkverbindung, Zugangsdaten und realen Speicher. Die Attrappe erlaubt zudem Zustände, die sich real kaum erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne Metadatum.
 
 \subsection{Abgedeckte Pfade}
 
-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.
-
-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.
+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. Denn die Anforderung war keine funktionale, sondern eine über den Aufwand: dass der Regelfall mit einem einzigen Zugriff auskommt, lässt sich nur über die beobachteten Aufrufe prüfen.
 
 \subsection{Befunde aus dem Review von Testcode}
 
-Zwei Reviewhinweise \emph{Timo Walters} betrafen nicht den Produktivcode, sondern die Tests selbst. Zum einen verwendeten Testdaten reale Kundennamen statt Platzhaltern — unnötig, da Versionsverwaltung dauerhaft lesbar bleibt und Platzhalter denselben Zweck erfüllen; die Daten wurden ersetzt. Zum anderen bestand ein Test aus dem falschen Grund: Er brach bereits in der ersten Zeile an einem unbekannten Typbezeichner ab, ohne die eigentlich zu prüfende Sicherheitseigenschaft — dass ein in die Adresse geschriebener Kundenname kein Ergebnis liefert — je zu erreichen.
-
-Der zweite Fund war nur durch Lesen, nicht durch Ausführen zu erzielen, da der Test grün war. Als Konsequenz wurde die Testabsicht explizit benannt; die Anforderung, dass ein Test ohne den jeweiligen Fix fehlschlagen muss, floss in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit ein (siehe Abschnitt~\ref{sec:race-conditions}).
+Zwei Reviewhinweise \emph{Timo Walters} betrafen die Tests selbst. Zum einen verwendeten Testdaten reale Kundennamen statt Platzhaltern; die Daten wurden ersetzt. Zum anderen bestand ein Test aus dem falschen Grund: Er brach bereits an einem unbekannten Typbezeichner ab, ohne die zu prüfende Sicherheitseigenschaft — dass ein in die Adresse geschriebener Kundenname kein Ergebnis liefert — je zu erreichen. Der Fund war nur durch Lesen zu erzielen, da der Test grün war. Als Konsequenz wurde die Anforderung, dass ein Test ohne den jeweiligen Fix fehlschlagen muss, in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (Abschnitt~\ref{sec:race-conditions}).