Ich habe dieses Thema mehr als einmal gesehen. Ich hoffe, dass Menschen hier, die sich in einer ähnlichen Situation befinden oder in der Vergangenheit waren, einen aufschlussreichen Rat geben können. Es könnte nützlich sein, wenn Sie auch Ihre vergangenen Erfahrungen teilen.
Also gibt es diese ziemlich große Windows Forms-Anwendung, die im Laufe der Jahre entwickelt wurde. Obwohl das Entwicklungsteam versucht hat, die Geschäftslogik von der Benutzeroberfläche zu trennen, ist dies nicht ganz geschehen und es gibt zahlreiche Bereiche des Codes, in denen die Geschäftslogik fest mit der Benutzeroberfläche verknüpft ist. In der Tat können Reste von früheren Versuchen, MVP-Architektur zu adoptieren, an vielen Orten gesehen werden. Es gibt auch Komponententests, aber mit einer relativ geringen Codeabdeckung. Es gibt jedoch einige Hotspots - Bereiche, von denen jeder weiß, dass sie komplizierter geworden sind, die sie notwendigerweise sein müssen.
Oftmals werden Bugs, die früher hätten erwischt werden können, erst gefunden, wenn die Tester ihre Fackellichter schnappen und wirklich nach Wanzen suchen, was leider zu spät, teuer und riskant ist. Ingenieure, Tester und PMs erkennen, dass etwas getan werden muss.
Was wäre der praktischste Weg, um die Situation insgesamt anzugehen oder die Situation zu verbessern? Da es eine lange Aufgabe sein wird, was wäre der beste Weg, um den Fortschritt in Richtung auf das Ziel zu messen? Wie wäre das Ziel zunächst objektiv zu definieren?
Sie müssen die Business-Schicht neu entwerfen und dann die Benutzeroberfläche wieder in diese neu gestaltete Ebene einbinden.
Sie behalten dabei die bestehende Benutzeroberfläche und die fest verdrahtete Geschäftslogik bei und wechseln sie jeweils einzeln in die neuen Formulare.
Dies hat den Vorteil, dass Sie alle Komponententests und automatisierten Testwerkzeuge hinzufügen können, die Sie benötigen, während die Effekte klein sind. Sie können auch sicherstellen, dass Ihre Komponenten das tun, was sie tun müssen.
Grundsätzlich handelt es sich um eine Long-Haul-Anlage mit kurzfristigem Return-on-Investment, die aber mittel- bis langfristig (wirklich nur lange) potenziell große Vorteile bietet.
Wie profitabel ist das Produkt? Wie groß ist das Team?
Diese Fragen werden Ihr Ausgangspunkt für eine Lösung sein. Je rentabler und größer das Team, desto schneller können Sie den Code auf ein neueres Formular umgestalten.
Aber bei großen Projekten besteht typischerweise eine große Gefahr durch Änderungen am Code. Es muss Bereiche geben, die "einfach funktionieren", die seit Jahren nicht mehr betrachtet wurden. Fehler in diesen Bereichen zu bekommen, wird eine große Herausforderung sein. Es wird eine Weile dauern, bis sich die Gänge drehen, um diese Bereiche zu debuggen.
Ich möchte jedoch den Code im Detail studieren. Wenn Sie wirklich sicher sind, dass Sie es kalt kennen, geben Sie eine Präsentation für andere, die in der Code-Basis kenntnisreich sind. Dadurch wird der nächste Codeabschnitt angezeigt, von dem Sie dachten, Sie wüssten ihn, aber nicht. Wenn der Code in Ihren Kopf eindringt, wird ein klareres Bild von dem, was benötigt wird, in Ihrem Kopf auftauchen. Dann sind Sie bereit, einen Plan für den ersten Schritt auszuarbeiten. Mach es vernünftig und beiße nicht zu sehr ab.
Vor allem, lerne und habe Spaß. Die Überarbeitung eines großen Projekts kann ziemlich viel Spaß machen, solange Sie die richtige Einstellung haben.
"Geschäftslogik dringt in die Benutzeroberfläche ein" ... Ich liebe die Wortwahl.
Natürlich ist ein schwieriger Teil das Unit-Testen der Benutzeroberfläche. Möglicherweise müssen Sie zuerst die Extract-Methode in der Benutzeroberfläche selbst ausführen, um die darin enthaltenen logischen Elemente zu testen und folgen Sie dann den obigen Schritten.
Klingt, als hättest du eine ziemliche Herausforderung vor dir!
Im weitesten Sinne denke ich, dass Sie zunächst mit Ihrem Team zusammenarbeiten müssen, um genau zu definieren, was Sie für akzeptabel und was nicht akzeptabel ist.
Nach meiner Erfahrung muss ein gewisses Maß an Geschäftslogik (z. B. Validierung) in der Benutzeroberfläche vorhanden sein (obwohl dies auch in der Business-Schicht erzwungen werden sollte).
Sobald Sie eine klare Definition dessen haben, was akzeptabel ist und was nicht, sollte es eine relativ mechanische (wenn auch entmutigende) Aufgabe sein, die Verstöße im Projekt aufzulisten.
Das gibt Ihnen einen deutlichen Hinweis auf das Ausmaß des Problems - und ist wirklich der einzige Ort, von dem aus Sie vernünftig ausgehen können, wenn Sie beabsichtigen, es in irgendeiner messbaren Weise zu lösen.
Tags und Links .net unit-testing