it-swarm.com.de

Schreiben von Tests für Code, dessen Zweck ich nicht verstehe

Ich habe kürzlich ein Black-Box-Refactoring abgeschlossen. Ich kann es nicht einchecken, da ich nicht herausfinden kann, wie ich es testen soll.

Auf einer hohen Ebene habe ich eine Klasse, deren Initialisierung das Abrufen von Werten aus einer Klasse B umfasst. Wenn Klasse B "leer" ist, werden einige sinnvolle Standardeinstellungen generiert. Ich habe diesen Teil mit einer Methode extrahiert, die Klasse B mit denselben Standardeinstellungen initialisiert.

Ich muss noch den Zweck/Kontext einer Klasse herausfinden oder wie sie verwendet werden würden. Daher kann ich das Objekt nicht aus einer leeren Klasse B initialisieren und überprüfen, ob es die richtigen Werte hat/das Richtige tut.

Meine beste Idee ist es, den ursprünglichen Code auszuführen, abhängig von den initialisierten Mitgliedern in den Ergebnissen öffentlicher Methoden fest zu codieren, und den neuen Code dagegen zu testen. Ich kann nicht genau sagen, warum ich mich mit dieser Idee vage unwohl fühle.

Gibt es hier einen besseren Angriff?

59
user214290

Dir geht es gut!

Das Erstellen automatisierter Regressionstests ist häufig das Beste, was Sie tun können, um eine Komponente überarbeitbar zu machen. Es mag überraschend sein, aber solche Tests können oft geschrieben werden, ohne vollständig zu verstehen, was die Komponente intern tut, solange Sie die Eingabe- und Ausgabeschnittstellen (im allgemeinen Sinne dieses Wortes) verstehen. Wir haben dies in der Vergangenheit mehrmals für vollständige Legacy-Anwendungen getan, nicht nur für Klassen, und es hat uns oft geholfen, zu vermeiden, dass Dinge kaputt gehen, die wir nicht vollständig verstanden haben.

Sie sollten jedoch über genügend Testdaten verfügen und sicherstellen, dass Sie genau wissen, was die Software aus Sicht eines Benutzers dieser Komponente tut. Andernfalls besteht die Gefahr, dass Sie wichtige Testfälle weglassen.

Es ist meiner Meinung nach eine gute Idee, Ihre automatisierten Tests zu implementieren vor Sie beginnen mit dem Refactoring, nicht danach, damit Sie das Refactoring in kleinen Schritten durchführen und jeden Schritt überprüfen können. Das Refactoring selbst sollte den Code besser lesbar machen, damit Sie das Verständnis der Interna Stück für Stück verbessern können. Die Bestellschritte in diesem Prozess sind also

  1. den Code "von außen" verstehen,
  2. regressionstests schreiben,
  3. refactor, was zu einem besseren Verständnis der Interna des Codes führt
122
Doc Brown

Ein wichtiger Grund für das Schreiben von Komponententests ist, dass sie die Komponenten-API irgendwie dokumentieren. Hier ist es wirklich ein Problem, den Zweck des zu testenden Codes nicht zu verstehen. Die Codeabdeckung ist ein weiteres wichtiges Ziel, das schwer zu erreichen ist, ohne zu wissen, welche Ausführungszweige vorhanden sind und wie sie ausgelöst werden.

Wenn es jedoch möglich ist, den Status sauber zurückzusetzen (oder das neue Testobjekt jedes Mal zu erstellen), kann man Tests vom Typ "Papierkorb in Papierkorb aus" schreiben, die nur meist zufällige Eingaben in das System einspeisen und die Ausgabe beobachten.

Solche Tests sind schwer aufrechtzuerhalten, da es schwierig sein kann zu sagen, warum und wie ernst es ist, wenn sie fehlschlagen. Die Abdeckung kann fraglich sein. Sie sind jedoch immer noch viel besser als nichts. Wenn ein solcher Test fehlschlägt, kann der Entwickler die neuesten Änderungen mit größerer Aufmerksamkeit überarbeiten und hoffentlich den Fehler dort erkennen.

1
h22