Leute, Ich habe eine große Legacy-.NET-Code-Basis, und ich versuche Unit Testing für das Team einzuführen. Sie sind gute Leute, aber das ist alles neu für sie (um ehrlich zu sein, es ist auch ziemlich neu für mich).
Eines der Probleme ist, dass die Codebasis in System.IO statische Klassen verwendet. Es gibt umfangreiche interne Bibliotheken von statischen Klassen und Klassen werden nicht in Schnittstellen geschrieben (es sei denn, es gibt einen tatsächlichen Entwurfsgrund dafür) ).
Ich entwickle eine Easy-in-Strategie mit NUnit und FakeItEasy.
Um die statischen Klassenabhängigkeiten zu adressieren, habe ich ein Werkzeug geschrieben, das Wrapper-Klassen und Schnittstellen für existierende statische Klassen generiert. z.B. In einer Konfigurationsdatei sage ich Wrapper für System.IO Directory & File , das Tool generiert eine Assembly mit Code in der Art von. . .
Die Idee ist, dass in der bestehenden Code-Basis kann einfach durch eine Suche / Ersetzen und Hinzufügen einer neuen Projektreferenz aktualisiert werden, und das in Unit-Tests können Sie ein Mock-Objekt zu IO.Instance zuweisen.
Auf der einen Seite bin ich ziemlich glücklich mit diesem Ansatz, es gibt einen sauberen und schnellen Weg weg von der Verwendung von statischen Klassen direkt und gibt uns eine Möglichkeit, diese statischen Klassen zu verspotten und lässt uns Code testen, der von ihnen abhängt .
Auf der anderen Seite habe ich das Gefühl, einen Deal mit dem Teufel gemacht zu haben. Ich habe Abhängigkeiten von impliziten Singletons durch Abhängigkeiten von expliziten Singletons ersetzt.
Wird das irgendwann in naher Zukunft für mich schrecklich schief gehen, oder glauben Sie, dass dies ein praktikabler Ansatz ist?
Ich würde tun, wie Sie es für eine Legacy-Anwendung getan haben. Nicht viel können Sie tun, ohne größere Stücke umgestalten zu müssen. Es ist immer noch flexibel, da Sie die Implementierung über die statische Klasse ändern können.
Eine Idee könnte sein, die Instance-Methode nur statisch zu machen und stattdessen die IO-Klasse in Ihrem IOC zu registrieren (als Singleton). Lassen Sie dann das IOC die richtige Implementierung finden (die von der statischen Instance-Methode zurückgegeben wird).
Schöne Einführung in IoC-Container: Ссылка
Tags und Links .net unit-testing singleton