{"id":626,"date":"2020-09-21T12:00:54","date_gmt":"2020-09-21T10:00:54","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=626"},"modified":"2020-09-21T12:08:11","modified_gmt":"2020-09-21T10:08:11","slug":"up-and-down","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/up-and-down\/","title":{"rendered":"Up and Down"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

Weiter geht es mit dem aufl\u00f6sen l\u00e4stiger Abh\u00e4ngigkeiten, um unseren Code unter Testkontrolle zu bringen und damit sicher \u00e4ndern k\u00f6nnen. Wenn ihr die Muster Expose Static Method oder Break Out Method Object<\/a> ausprobiert habt, habt ihr m\u00f6glicherweise festgestellt, dass diese beiden Refactoring Pattern ihre Grenzen haben. Was tun, wenn zu viele Methoden der Klasse aufgerufen werden, die uns im Test \u00fcberhaupt nicht interessieren?<\/p>\n

In diesem Fall k\u00f6nnen wir die Methoden auf unterschiedliche Ober- oder Unterklassen aufteilen um dadurch die Koh\u00e4renz der einzelnen Klassen zu erh\u00f6hen. 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\u00e4llig wird ist dabei ein positiver Nebeneffekt<\/span><\/p>\n

Pull up Feature<\/h2>\n

Ziel:<\/strong><\/p>\n

Doppelte Implementierungen in Unterklassen, die durch gewachsenen Code entstanden sind, werden f\u00fcr den Test durch Verschieben in eine Oberklasse aufgel\u00f6st. Damit ist es m\u00f6glich, fokussierte Tests f\u00fcr relevante Features zu schreiben.<\/span><\/p>\n

Anleitung:<\/strong><\/p>\n

    \n
  1. Methoden identifizieren, die in eine Oberklasse verlagert werden sollen<\/li>\n
  2. Abstrakte Oberklasse mit diesen Methoden erstellen<\/li>\n
  3. Methoden in die Oberklasse kopieren und kompilieren (Lean on the Compiler)<\/li>\n
  4. Fehlende Referenzen in die Oberklasse kopieren (Preserve Signatures)<\/li>\n
  5. Unterklasse der abstrakten Klasse erstellen und Methoden einf\u00fcgen, die f\u00fcr den Test ben\u00f6tigt werden<\/li>\n<\/ol>\n

    Push down Dependency<\/h2>\n

    Ziel:<\/strong><\/p>\n

    Eine bei der Erstellung als allgemeing\u00fcltig gedachte Methode, die aber nur in einer oder wenigen Unterklassen verwendet wird, wird an die Stelle verschoben, an der sie relevant ist.<\/p>\n

    Anleitung:<\/strong><\/p>\n

      \n
    1. Klasse mit Abh\u00e4ngigkeiten im Test-Harnisch kompilieren<\/li>\n
    2. Abh\u00e4ngigkeiten durch Compiler identifizieren<\/li>\n
    3. Unterklasse erstellen (Name dr\u00fcckt die Abh\u00e4ngigkeit aus)<\/li>\n
    4. Methoden zu Abh\u00e4ngigkeiten in Unterklasse kopieren, Methoden in Oberklasse protected oder abstract deklarieren; Oberklasse (urspr\u00fcngliche Klasse) abstrakt machen<\/li>\n
    5. Test-Unterklasse erstellen und diese im Test verwenden<\/li>\n
    6. Test kompilieren<\/li>\n<\/ol>\n

      Zusammenfassung<\/h2>\n

      Durch die genannten Refactoring-Patterns verkleinern wir den getesteten Code und haben damit mehr Flexibilit\u00e4t bei weiteren Refactorings. Auch wird die Testabdeckung fokussierter und bietet uns damit mehr Sicherheit bei weiteren Refactorings und Umbauten des (Legacy-)Codes.<\/p>\n

      Wir w\u00fcnschen euch viel Spa\u00df beim Ausprobieren.<\/p>\n

      Eure Spa\u00df-Coder<\/p>\n

      Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:<\/p>\n

        \n
      • Feathers, Michael C. Effektives Arbeiten mit Legacy Code: Refactoring und Testen bestehender Software<\/i>. mitp Verlags GmbH & Co. KG, 2011.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

        Hallo Spa\u00df-Coder. Weiter geht es mit dem aufl\u00f6sen l\u00e4stiger Abh\u00e4ngigkeiten, um unseren Code unter Testkontrolle zu bringen und damit sicher \u00e4ndern k\u00f6nnen. Wenn ihr die Muster Expose Static Method oder Break Out Method Object ausprobiert habt, habt ihr m\u00f6glicherweise festgestellt, dass diese beiden Refactoring Pattern ihre Grenzen haben. Was tun, wenn zu viele Methoden der […]<\/p>\n","protected":false},"author":2,"featured_media":1271,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[90],"tags":[53],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/626"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=626"}],"version-history":[{"count":4,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/626\/revisions"}],"predecessor-version":[{"id":1265,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/626\/revisions\/1265"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/1271"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}