Gute Tests, schlechte Tests | Komentor

Unit-Tests sind nur eine weitere Praxis, und als solche hat es seine Vorteile und seine Kosten. Woher wissen Sie, dass sich Ihre Testsuite auszahlt?

Unit-Tests können, wie jede Praxis, ins Absurde getrieben werden. Ich habe bereits an geschrieben IGs Blog darüber.

Die Wahrheit ist, dass das Schreiben guter Tests genauso schwierig ist wie das Schreiben von gutem Produktionscode. Es erfordert Übung und sorgfältige Überlegung, aber ich habe so oft gesehen, wie Tests als Bürger zweiter Klasse behandelt werden, was normalerweise bedeutet, dass wir nicht alle Vorteile einer guten Testsuite nutzen und am Ende Suiten haben, die mehr sind eine Belastung als eine Bereicherung.

Eine gute Testsuite:

  1. Gibt Ihnen Selbstvertrauen.
  2. Findet Fehler.
  3. Ist günstig im Unterhalt.
  4. Dokumentieren Sie das System.
  5. Robustheit.
  6. Hat keine Fehler.
  7. Es läuft.

Vertrauen

Reicht das Ausführen Ihres Tests nach dem Vornehmen einer Änderung aus, um den Code festzuschreiben? Und für die Produktion bereitstellen?

Meine Erfahrung sagt mir, dass Unit-Tests nicht ausreichen und irgendwie voller StapelBDD und Integrationstests sind erforderlich, um das Vertrauensniveau zu erhöhen.

Beachten Sie, dass, wenn zwei Tests Ihnen Vertrauen in denselben Bereich/dieselbe Funktion geben, einer davon überflüssig ist.

Wenn Sie Ihren Tests wirklich vertrauen, aber immer noch Fehler an die Produktion senden, ist Ihr Vertrauen fehl am Platz.

Fehler finden

Wenn Sie eine Testsuite haben, die niemals rot wird, geben Ihnen Ihre Tests keinen Wert, da sie keine Fehler abfangen, was ihr Hauptgrund dafür ist.

Günstig im Unterhalt

Wenn Sie beim Refactoring Ihres Codes feststellen, dass Sie viel Zeit damit verbringen, Ihre Tests zu korrigieren oder neu zu schreiben, zahlt sich Ihre Testsuite nicht aus. Ich habe festgestellt, dass dies besonders zutrifft, wenn Ihre Einheit die Klasse ist und wenn Sie viele Scheinobjekte verwenden – in den meisten Fällen landen Sie damit überspezifizierte Software.

Dokumentieren

Tests sollten uns sagen, was das System tut und idealerweise warum es es tut.

Ein Mindestsatz von Tests sollte uns auch sagen, wie es funktioniert, aber mit der Erwartung, dass diese Tests verworfen werden, wenn wir ein umfangreiches Refactoring durchführen.

Keine Fehler

Der beste Weg, um zu wissen, dass ein Test testet, was er testen soll, dh dass der Test keine Fehler enthält, besteht darin, zu sehen, wie der Test von Rot auf Grün wechselt, wenn Sie eine Änderung in Ihrem Produktionscode vornehmen.

Aus diesem Grund sollten Sie den Test vor dem Produktionscode schreiben.

Bedenken Sie auch Mutationstests um die blinden Flecken in Ihrer Suite zu finden.

Robust

Wenn Ihre Testsuite einen fehlerhaften Test hat, einen, der zufällig rot wird, wird dies die gesamte Testsuite untergraben, da sich die Leute nicht mehr darum kümmern.

Es ist besser, die schuppigen Tests zu entfernen, als sie herumliegen zu lassen.

Laufen

Vielleicht klingt das ein bisschen albern, aber ich habe viele Tests gesehen und geschrieben, die nicht zum Ausführen einluden. Diese enthielten:

  • Auskommentierte oder @Ignorierte Tests.
  • Sehr langsame Tests.
  • Tests, die einige manuelle Schritte erfordern, wie die Installation einer Datenbank, eines Anwendungscontainers oder eines Nachrichtenbrokers.
  • Tests, die nicht von Ihrer IDE aus ausgeführt oder debuggt werden können.

Zusammenfassend lässt sich sagen, dass eine gute Testsuite die Säule sein wird, die es uns ermöglicht, unsere Systeme weiterzuentwickeln und zu ändern.

Tests müssen Veränderungen unterstützen nicht hemmen.

Am Ende des Tages als Dave Thomas und Andy Hunt weise hinweisenändern wir immer ein bestehendes System.

Die gesamte Programmierung ist Wartungsprogrammierung, da Sie selten Originalcode schreiben.

Es sind nur die ersten 10 Minuten, die der Code original ist, wenn Sie ihn zum ersten Mal eingeben. Das ist es.

Similar Posts

Leave a Reply

Your email address will not be published.