Tests als Nachweise nutzen

Beginnen Sie mit der Anforderung

Tests liefern Nachweise für konkrete Aussagen. Ein erfolgreicher Testlauf belegt nicht jede Eigenschaft der Software. Bestimmen Sie vor der Anforderung von Tests das relevante Verhalten und den Fehler, den jede Prüfung erkennen soll.

Bei einem fiktiven Organisationsexport ist Datentrennung die zentrale Anforderung. Ein Nutzer in Organisation A darf keine Datensätze aus Organisation B erhalten. Ein Test, der nur einen erfolgreichen Download prüft, belegt diese Anforderung nicht.

Bitten Sie den Agenten, den Zusammenhang zwischen Anforderung und Assertion zu erklären. So lassen sich fehlende Fälle leichter erkennen, bevor die Testsuite groß wird.

Wählen Sie den passenden Testumfang

Ein Unit-Test kann eine kleine Umwandlung schnell prüfen. Ein Integrationstest kann das Zusammenspiel von Komponenten prüfen. Ein End-to-End-Test kann einen wichtigen Nutzerablauf durch die bereitgestellte Anwendung oder eine repräsentative Variante prüfen.

Nutzen Sie den kleinsten Umfang, der den erforderlichen Nachweis liefert. Ein Formatierer braucht nicht für jede Eingabe einen vollständigen Browsertest. Eine Autorisierungsgrenze kann eine echte Route und den tatsächlichen Datenzugriffspfad erfordern. Eine kritische Browserinteraktion braucht Nachweise zur gerenderten Oberfläche.

Kein fester prozentualer Mix aus Testtypen passt zu jedem System. Wählen Sie nach dem zu erkennenden Fehler und dem Wartungsaufwand der Prüfung.

Vermeiden Sie dieselbe falsche Annahme in Code und Test

Ein Agent kann Implementierung und Tests aus demselben Missverständnis entwickeln. Beide können zusammenpassen, obwohl die Anforderung unerfüllt bleibt.

Angenommen, die Implementierung filtert Datensätze nach der Organisations-ID aus der Anfrage. Der Test verwendet dieselbe ID für den angemeldeten Nutzer und die Anfrage. Er besteht. Der fehlende Fall ist ein Nutzer, der die ID einer anderen Organisation anfordert.

Ergänzen Sie diesen Fall über den tatsächlichen vertrauenswürdigen Identitäts- und Autorisierungspfad. Ein Mock, der immer „erlaubt“ zurückgibt, kann Mandantentrennung nicht belegen. Er belegt nur das Verhalten nach erfolgreicher Autorisierung.

Prüfen Sie, ob der Test fehlschlagen kann

Führen Sie bei einem bekannten Fehler den neuen Regressionstest in einem isolierten Branch gegen die fehlerhafte Version aus. Prüfen Sie, ob er aus dem vorgesehenen Grund fehlschlägt. Wenden Sie anschließend die Korrektur an und führen Sie ihn erneut aus.

Ein Test, der wegen einer nicht ladbaren Fixture fehlschlägt, liefert noch keinen Nachweis über das fachliche Verhalten. Prüfen Sie den Fehler und nicht nur den Exit-Code.

Bei umfassenderen Änderungen können Mutationstests zeigen, ob ausgewählte Codeänderungen Testfehler auslösen. Das verursacht Aufwand und ersetzt keine Anforderungsprüfung. Nutzen Sie diese Methode dort, wo die zusätzlichen Nachweise eine folgenreiche Entscheidung unterstützen.

Halten Sie Nachweise und Änderung zusammen

Führen Sie die relevanten Prüfungen an der endgültigen Revision aus. Dokumentieren Sie ausgelassene Prüfungen mit ihren Gründen. Ein Ergebnis aus einem früheren Commit gilt nach einer Review-Korrektur möglicherweise nicht mehr.

Halten Sie Tests verständlich. Bevorzugen Sie einen ausdrücklichen Aufbau und eine klare Assertion gegenüber einer umfangreichen Hilfsfunktion, die die wichtige Bedingung verbirgt. Entfernen Sie redundante Prüfungen, wenn sie Wartungsaufwand verursachen, ohne einen anderen Fehler zu erkennen.

Der Reviewer sollte erklären können, was die Tests belegen und was ungeklärt bleibt. Diese Erklärung ist nützlicher als eine hohe Testanzahl.