Jemand, der mit der Erstellung eines "Core" -Bausatzes von Bibliotheken beauftragt ist, hat eine Reihe von statischen Klassen erstellt, die alle Arten von Dienstprogrammen von Logging, Auditing und allgemeinen Datenbankzugriffsmethoden bereitstellen.
Ich persönlich denke, das stinkt, weil wir jetzt einen Core-Satz von Bibliotheken haben, die schwer zu testen sind, weil ich diese Klassen nicht stupsen kann / stubele oder irgendeine Injektion in ihre Konstruktoren mache.
Ich nehme an, dass ich TypeMock verwenden kann, um diese auszuschließen, aber ich würde es lieber kostenlos machen.
Was denkst du?
Bearbeiten
Wenn Sie nicht glauben, dass sie schwer zu testen sind, können Sie ein Beispiel geben, wie Sie sie testen würden. Diese statischen Klassen instanziieren andere Typen, um ihre Funktionen auszuführen.
Statische Klassen (Methoden) müssen nicht unbedingt vermieden werden, solange sie keine versteckten Abhängigkeiten haben. Natürlich können Sie Abhängigkeiten in eine statische Methode übergeben - sie sollte nicht intern gespeichert werden und das Verhalten späterer Aufrufe ändern.
Auch in diesem Fall sollte es kein Problem geben, sie zu testen.
Aber ich habe auch ein schlechtes Gefühl für die Fälle, die Sie erwähnt haben. Ich kenne einige dieser statischen "Wrapper" Utility-Klassen - und in den meisten Fällen stinken sie wirklich:)
BEARBEITEN:
Vielleicht sollte ich das klären. Ich würde statische Klassen / Methoden nur für sehr kleine Aufgaben verwenden. Wenn statische Klassen beginnen, Abhängigkeiten zu initialisieren, sollten sie mit Sicherheit vermieden werden. Wenn Sie diese statischen Klassen nicht testen können, haben sie bereits eine zu große Aufgabe.
In der ersten Antwort auf diese Frage stehen die Argumente dagegen statische Klassen wie du erwähnt hast.
Wie schwer wäre es, diese statischen Klassen zu modifizieren, um Dependency Injection zu nutzen? Wenn Sie das DI optional machen (wenn möglich), können Sie im Wesentlichen eine Situation schaffen, in der Sie die statischen Klassen zum Spotten verwenden können, indem Sie einfach die DI ausführen, während Sie das "normale" Verhalten nicht ändern.
Statische Methoden behindern die Entwicklung von Tests durch hardwiring instance creation. Eine Untersuchung von 120 statischen Methoden im Open-Source-Smalltalk-Code zeigt, dass von den 120 statischen Methoden nur 6 nicht genauso gut wie Instanzmethoden implementiert werden konnten, dies aber nicht taten und somit den Aufrufer mit der impliziten Abhängigkeit von diesen statischen Methoden belasteten / p>
Tags und Links c# dependency-injection mocking testability