Tautologische Tests werden manchmal als Tests bezeichnet, die zu eng mit der zugrunde liegenden Implementierung verbunden sind, und werden buchstäblich Schritt für Schritt wiederholt. Sie werden regelmäßig beschimpft, und im Allgemeinen scheinen Entwickler in der Lage zu sein, sie zu umgehen und zu erkennen. Unter dem Druck des Managements werden solche Tests manchmal rückwirkend durchgeführt, um die Berichterstattung nachzuholen.
Es gibt jedoch komplexe Fälle.
- Der erste Fall sind Tests, die das Verhalten von Bibliotheken reproduzieren. Ein typischer Fall ist ein http-Client aus einer Bibliothek, in der Sie einen Client erstellen, Cookies und Header einfügen und eine Anfrage senden müssen. Es macht keinen Sinn, jeden Schritt zu testen. Möglicherweise gibt es noch statische Methoden, neue und andere Testkiller-Killer. Daher ist es am einfachsten, sie in eine dünne Wrapper-Klasse zu packen. Unit-Tests sind für eine solche Klasse nicht erforderlich. Sie können diese Klasse im Kontext von Abhängigkeitsintegrationstests testen, dh, wir nennen sie gegen einen echten Service und stellen sicher, dass die Bibliothek wie erwartet funktioniert. Es ist wichtig, dass die Wrapper-Klasse keine zusätzliche Logik enthält, die als Teil des Komponententests getestet werden kann.
- Der zweite Fall sind Tests, die etwas überprüfen, das kein Ergebnis liefert (oder etwas Unscharfes). Die einzige Möglichkeit zu überprüfen, ob etwas aufgerufen wurde, ist Spy mit einem Zähler. Dies ist ein gültiger, wenn auch begrenzter Fall. Dies kann aufgerufene gespeicherte Prozeduren und das Senden von E-Mails einschließen.
- Der dritte Fall sind Tests von Strategien, Richtlinien und anderen Verhaltensmustern. Zum Beispiel möchten wir, dass beim Erstellen einer Bestellung ein Datensatz in der Datenbank gespeichert wird, dieser in die Bestellwarteschlange gestellt wird und dann etwas in die Protokolle und E-Mails geschrieben wird.
Es ist wichtig zu verstehen, dass unser Test in diesem Fall eine Spezifikation einer Regel, eines Verhaltens ist. Das heißt, er schreibt vor, in welcher Reihenfolge die Komponenten gezogen werden, nicht weil er ihnen folgt, sondern weil er ihnen folgt. In diesem Sinne ist es logisch, es abstrakter zu schreiben: Wenn Sie beispielsweise mehrere Dienste aufrufen müssen - jedenfalls parallel oder nacheinander -, sollte der Test genau das beschreiben. Wenn Objekte Tests werfen, sollte er wahrscheinlich nicht mit der Nase in die Felder dieses Objekts stecken. Daher kann unser Test fast wie eine Implementierung aussehen oder als die einfachste und naivste Implementierung eines Verhaltens, kennen aber gleichzeitig das Maß im Detail und sind keine Tautologie.
Manchmal fließen diese Fälle jedoch ineinander. Das heißt Es kann sein, dass wir mehrere Anrufe bei älteren Bibliotheken haben, die nichts wirklich zurückgeben oder sich unverständlich mit dem austauschen, was jemandem, der gegründet wurde, nicht bekannt ist, und es ist nicht ganz klar, wer wem das Verhalten „vorschreibt“. Das Testen ist wie das Erläutern einer Route für einen Busfahrer. Befolgen Sie daher am besten das erste Szenario.