Up and Down

Hallo Spaß-Coder.

Weiter geht es mit dem auflösen lästiger Abhängigkeiten, um unseren Code unter Testkontrolle zu bringen und damit sicher ändern können. Wenn ihr die Muster Expose Static Method oder Break Out Method Object ausprobiert habt, habt ihr möglicherweise festgestellt, dass diese beiden Refactoring Pattern ihre Grenzen haben. Was tun, wenn zu viele Methoden der Klasse aufgerufen werden, die uns im Test überhaupt nicht interessieren?

In diesem Fall können wir die Methoden auf unterschiedliche Ober- oder Unterklassen aufteilen um dadurch die Kohärenz der einzelnen Klassen zu erhöhen. Dies erleichtert den Test durch entsprechende Trennung der Verantwortlichkeiten. Die Testaufrufe testen weniger irrelevanten Code und lassen sich auf das Wesentliche fokussieren. Dass auch der Code kleiner, lesbarer und weniger Fehleranfällig wird ist dabei ein positiver Nebeneffekt

Pull up Feature

Ziel:

Doppelte Implementierungen in Unterklassen, die durch gewachsenen Code entstanden sind, werden für den Test durch Verschieben in eine Oberklasse aufgelöst. Damit ist es möglich, fokussierte Tests für relevante Features zu schreiben.

Anleitung:

  1. Methoden identifizieren, die in eine Oberklasse verlagert werden sollen
  2. Abstrakte Oberklasse mit diesen Methoden erstellen
  3. Methoden in die Oberklasse kopieren und kompilieren (Lean on the Compiler)
  4. Fehlende Referenzen in die Oberklasse kopieren (Preserve Signatures)
  5. Unterklasse der abstrakten Klasse erstellen und Methoden einfügen, die für den Test benötigt werden

Push down Dependency

Ziel:

Eine bei der Erstellung als allgemeingültig gedachte Methode, die aber nur in einer oder wenigen Unterklassen verwendet wird, wird an die Stelle verschoben, an der sie relevant ist.

Anleitung:

  1. Klasse mit Abhängigkeiten im Test-Harnisch kompilieren
  2. Abhängigkeiten durch Compiler identifizieren
  3. Unterklasse erstellen (Name drückt die Abhängigkeit aus)
  4. Methoden zu Abhängigkeiten in Unterklasse kopieren, Methoden in Oberklasse protected oder abstract deklarieren; Oberklasse (ursprüngliche Klasse) abstrakt machen
  5. Test-Unterklasse erstellen und diese im Test verwenden
  6. Test kompilieren

Zusammenfassung

Durch die genannten Refactoring-Patterns verkleinern wir den getesteten Code und haben damit mehr Flexibilität bei weiteren Refactorings. Auch wird die Testabdeckung fokussierter und bietet uns damit mehr Sicherheit bei weiteren Refactorings und Umbauten des (Legacy-)Codes.

Wir wünschen euch viel Spaß beim Ausprobieren.

Eure Spaß-Coder

Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:

  • Feathers, Michael C. Effektives Arbeiten mit Legacy Code: Refactoring und Testen bestehender Software. mitp Verlags GmbH & Co. KG, 2011.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert