Das Hauptproblem mit Legacy-Code ist, dass es keine Tests gibt. Sie müssen also einige hinzufügen (und dann noch mehr ...).
Dies an sich würde, wie @mattnz feststellte, eine Menge Arbeit kosten. Aber das besondere Problem des Legacy - Code ist , dass es nie testbar wurde entwickelt . In der Regel handelt es sich also um ein gewaltiges Durcheinander von Spaghetti-Code, bei dem es sehr schwierig oder gar nicht möglich ist, zu prüfende Kleinteile zu isolieren. Daher müssen Sie den Code vor dem Unit-Test überarbeiten , um ihn testbarer zu machen.
Um jedoch sicher umgestalten zu können, müssen Sie Unit-Tests durchführen, um sicherzustellen, dass Sie mit Ihren Änderungen nichts angestellt haben ... Dies ist der Haken 22 des Legacy-Codes.
Das Buch zeigt Ihnen, wie Sie aus diesem Haken ausbrechen, indem Sie die absolut minimalen und sichersten Änderungen am Code vornehmen, nur um die ersten Komponententests zu ermöglichen. Diese sollen das Design nicht schöner machen, sondern nur Unit-Tests ermöglichen. In der Tat machen sie manchmal das Design hässlicher oder komplexer. Mit ihnen können Sie jedoch Tests schreiben - und sobald Sie Komponententests durchgeführt haben, können Sie das Design verbessern.
Es gibt viele Tricks, um den Code testbar zu machen - einige sind offensichtlich, andere überhaupt nicht. Es gibt Methoden, an die ich niemals gedacht hätte, ohne das Buch zu lesen. Noch wichtiger ist jedoch, dass Feathers erklärt, was eine Code-Einheit genau testbar macht. Sie müssen Abhängigkeiten reduzieren und Barrieren in Ihren Code einführen, jedoch aus zwei verschiedenen Gründen:
- Erkennen - um die Auswirkungen der Ausführung eines Codes zu überprüfen und zu verifizieren, und
- Trennung - um das spezifische Stück Code zunächst in ein Testgeschirr zu bekommen.
Das sichere Trennen von Abhängigkeiten kann schwierig sein. Das Einführen von Interfaces, Mocks und Dependency Injection ist ein sauberes und ansprechendes Ziel, das zu diesem Zeitpunkt jedoch nicht unbedingt sicher ist. Daher müssen wir manchmal auf die Unterklasse der getesteten Klasse zurückgreifen, um eine Methode zu überschreiben, die normalerweise z. B. eine direkte Anforderung an einen DB startet. In anderen Fällen müssen wir möglicherweise sogar eine Abhängigkeitsklasse / jar in der Testumgebung durch eine gefälschte ersetzen ...
Das wichtigste Konzept von Feathers sind für mich die Nähte . Eine Naht ist eine Stelle im Code, an der Sie das Verhalten Ihres Programms ändern können, ohne den Code selbst zu ändern . Nähte in Ihr Code - Aufbau ermöglicht trennt das Stück im Test befindlichen Code, aber es ermöglicht Ihnen auch zu spüren , das Verhalten des Codes im Test auch dann , wenn es schwierig oder unmöglich ist , direkt zu tun (zB weil der Anruf tätigt Änderungen in einem anderen Objekt oder Subsystem , deren Status nicht direkt aus der Testmethode heraus abgefragt werden kann).
Mit diesem Wissen können Sie die Keime der Testbarkeit im schlimmsten Haufen Code erkennen und die minimalen, am wenigsten störenden und sichersten Änderungen finden, um dahin zu gelangen. Mit anderen Worten, zu vermeiden „offensichtlich“ Refactorings zu machen , die ein Risiko des Brechens des Codes haben , ohne dass Sie es merken - weil Sie nicht noch die Unit - Tests haben , dass zu erkennen.