Ich bin einem Team beigetreten, das an einem Produkt arbeitet. Dieses Produkt gibt es seit ca. 5 Jahren und verwendet ASP.NET WebForms. Seine ursprüngliche Architektur ist im Laufe der Zeit verblasst, und die Dinge sind in der gesamten Lösung relativ unorganisiert geworden. Es ist keineswegs schrecklich, aber kann definitiv etwas Arbeit gebrauchen; ihr alle wisst was ich meine.Refactoring für Testability auf einem vorhandenen System
Ich habe einige Refactorings durchgeführt, seit ich vor ungefähr 6 Monaten zum Projektteam kam. Einige dieser Refactorings sind einfach, Extract Method, Pull Method Up usw. Einige der Refactorings sind struktureller. Die letztgenannten Änderungen machen mich nervös, da es keine umfassende Suite von Komponententests für jede Komponente gibt. Das gesamte Team ist an Bord für die Notwendigkeit, strukturelle Änderungen durch Refactoring vorzunehmen, aber unser Projektmanager hat Bedenken geäußert, dass wir keine ausreichenden Tests haben, um Refactorings mit der Gewissheit durchzuführen, dass wir keine Regressionsfehler einführen in das System. Er möchte, dass wir zuerst mehr Tests (gegen die vorhandene Architektur) schreiben und dann die Refactorings durchführen. Mein Argument ist, dass die Klassenstruktur des Systems zu eng gekoppelt ist, um adäquate Tests zu schreiben, und dass die Verwendung eines mehr Test Driven-Ansatzes, während wir unsere Refactorings durchführen, besser sein kann. Was ich damit meine, ist nicht das Schreiben von Tests gegen die vorhandenen Komponenten, sondern das Schreiben von Tests für spezifische funktionale Anforderungen, dann Refactoring bestehenden Code, um diese Anforderungen zu erfüllen. Dies wird uns erlauben, Tests zu schreiben, die wahrscheinlich mehr Langlebigkeit im System haben werden, anstatt eine Menge "Wegwerf" -Tests zu schreiben.
Hat jemand irgendwelche Erfahrung, was die beste Vorgehensweise ist? Ich habe meine eigenen Gedanken, möchte aber etwas von der Community hören.