33 lines
4.4 KiB
TeX
33 lines
4.4 KiB
TeX
\section{Unit-Tests}
|
|
\label{sec:unit-tests}
|
|
|
|
\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.
|
|
|
|
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.
|
|
|
|
\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.
|
|
|
|
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.
|
|
|
|
\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.
|
|
|
|
\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.
|
|
|
|
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.
|
|
|
|
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 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}).
|