Refactoring für Testbarkeit auf einem bestehenden System

Question

Ich bin einem Team beigetreten, das an einem Produkt arbeitet.Dieses Produkt gibt es seit ca. 5 Jahren und es verwendet ASP.NET WebForms.Die ursprüngliche Architektur ist im Laufe der Zeit verblasst und die gesamte Lösung ist relativ unorganisiert.Es ist keineswegs schrecklich, kann aber auf jeden Fall etwas Arbeit gebrauchen;Ihr wisst alle, was ich meine.

Seit ich vor etwa sechs Monaten zum Projektteam gestoßen bin, habe ich einige Refactorings durchgeführt.Einige dieser Refactorings sind einfach: Methode extrahieren, Methode hochziehen usw.Einige der Refactorings sind eher struktureller Natur.Die letztgenannten Änderungen machen mich nervös, da es nicht für jede Komponente eine umfassende Suite von Komponententests gibt.

Das gesamte Team ist mit der Notwendigkeit einverstanden, durch Refactoring strukturelle Änderungen vorzunehmen, aber unser Projektmanager hat einige Bedenken geäußert, dass wir nicht über ausreichende Tests verfügen, um Refactorings mit der Gewissheit durchzuführen, dass wir keine Regressionsfehler in das System einführen.Er möchte, dass wir zuerst weitere Tests schreiben (gegen die bestehende Architektur) und dann die Refactorings durchführen.Mein Argument ist, dass die Klassenstruktur des Systems zu eng gekoppelt ist, um angemessene Tests zu schreiben, und dass es möglicherweise besser ist, bei der Durchführung unserer Refactorings einen stärker testgesteuerten Ansatz zu verwenden.Damit meine ich nicht das Schreiben von Tests für die vorhandenen Komponenten, sondern das Schreiben von Tests für bestimmte funktionale Anforderungen und die anschließende Umgestaltung des vorhandenen Codes, um diese Anforderungen zu erfüllen.Dies wird es uns ermöglichen, Tests zu schreiben, die wahrscheinlich eine längere Lebensdauer im System haben, anstatt eine Reihe von „Wegwerf“-Tests zu schreiben.

Hat jemand Erfahrung, was die beste Vorgehensweise ist?Ich habe meine eigenen Gedanken, würde aber gerne etwas Input von der Community hören.

Answer 1

Die Bedenken Ihres PM sind berechtigt. Stellen Sie sicher, dass Sie Ihr System testen, bevor Sie größere Umgestaltungen vornehmen.

Ich würde dringend empfehlen, sich ein Exemplar von Michael Feathers Buch zu besorgen Effektives Arbeiten mit Legacy-Code (Mit „Legacy Code“ bezeichnet Feathers jedes System, das nicht ausreichend durch Unit-Tests abgedeckt wird.)Dies ist voll von guten Ideen, wie Sie die Kopplungen und Abhängigkeiten, von denen Sie sprechen, auf sichere Weise auflösen können, ohne dass das Risiko besteht, dass Regressionsfehler entstehen.

Viel Glück mit dem Refactoring-Programm;Meiner Erfahrung nach ist es ein angenehmer und befreiender Prozess, aus dem man viel lernen kann.

Answer 2

Können Sie parallel umfaktorisieren?Damit meine ich, dass Sie die Teile, die Sie umgestalten möchten, mithilfe von TDD neu schreiben, aber die vorhandene Codebasis beibehalten müssen.Dann den vorhandenen Code auslaufen lassen, wenn Ihre neuen Tests die Anforderungen Ihres PM erfüllen?

Answer 3

Ich würde auch gerne einen Vorschlag für einen Besuch machen Refactoring Website von Martin Fowler.Er hat buchstäblich das Buch zu diesem Thema geschrieben.

Was die Einführung von Unit-Tests in die Gleichung betrifft, besteht die beste Methode, die ich gefunden habe, darin, eine Komponente der obersten Ebene zu finden, alle externen Abhängigkeiten zu identifizieren, die sie von konkreten Objekten hat, und sie durch Schnittstellen zu ersetzen.Sobald Sie dies getan haben, wird es viel einfacher sein, Komponententests für Ihre Codebasis zu schreiben, und Sie können dies für eine Komponente nach der anderen tun.Noch besser: Sie müssen keine Unit-Tests wegwerfen.

Unit-Tests von ASP.Net können schwierig sein, aber es gibt zahlreiche Frameworks, die dies einfacher machen. ASP.Net MVC, Und WCSF um ein paar zu nennen.

Answer 4

Ich möchte nur eine zweite Empfehlung für „Working Effectively with Legacy Code“ aussprechen, ein ausgezeichnetes Buch, das mir wirklich die Augen dafür geöffnet hat, dass fast jeder alte/beschissene/untestbare Code manipuliert werden kann!

Answer 5

Ich stimme der Antwort von voll und ganz zu Ian Nelson.Darüber hinaus würde ich damit beginnen, einige „High-Level“-Tests (Funktions- oder Komponententests) durchzuführen, um das Verhalten aus der Sicht des Benutzers zu bewahren.Dieser Punkt könnte für Ihren PM das wichtigste Anliegen sein.