Sollte ich niemals statische Methoden, Klassen und Singletons verwenden, wenn ich dem Paradigma der testgetriebenen Entwicklung folge?

Question

Ich habe gelesen, dass statische Methoden, statische Klassen und Singletons böse sind, wenn Sie versuchen, Unit-Tests in Ihrem Projekt zu implementieren.Sollte ich, wenn ich dem TDD-Paradigma folge, einfach vergessen, dass sie jemals existiert haben, und sie nie wieder verwenden, oder ist es in Ordnung, sie manchmal zu verwenden?

Answer 1

Sagen Sie niemals nie - statische Klassen und Methoden haben ihren Platz in Ihrer Toolbox.

das heißt, wenn die Klasse, wenn Sie versuchen, zu isolieren und zu testen (Untertest oder SUT) von einer statischen Klasse oder Methode abhängig sind, können Sie keinen Test schreiben, der die SUT von dieser statischen Abhängigkeit isoliert - wann Ihr Testcode läuft, es wird immer noch den statischen Anruf verwenden. Manchmal ist dies in Ordnung, aber manchmal möchten Sie einen isolierten Test erstellen, der nur die Logik Ihres SUT ohne Abhängigkeiten testet (normalerweise über spöttische oder ähnliche Techniken).

Im Allgemeinen verwende ich persönlich statische Klassen und Methoden relativ sparsam.

Aufgrund der Natur, wie Singletons implementiert sind, präsentieren sie ein ähnliches Problem zum Isolieren einer SUT-Prüfung. Darüber hinaus gilt das GOF-Singleton-Konzept als schlechte Praxis von einem bestimmten Prozentsatz von Softwareentwicklern. Ich stimme diesem Gefühl zufällig zu, aber es gibt kaum Konsens zu diesem Thema. Eine schnelle Suche bei Google wird Ihnen wahrscheinlich eine ziemlich gute Idee von den Vor- und Nachteilen des GOF-Singleton-Musters geben.

Answer 2

1. Sollten Sie vergessen, dass sie jemals existierten?NEIN.
2. Sollten Sie sicherstellen, dass ihre Einbindung in Ihren Code so erfolgt, dass sie für die Funktionalität einer Klasse transparent sind?Ja.

Um den letzten Teil näher zu erläutern: Versuchen Sie, anstatt zu versuchen, einen Wert aus einem Singleton in Ihrem Code abzurufen, den Wert innerhalb eines Konstruktorarguments zu initialisieren.Wenn Ihr Konstruktor zu groß wird, erstellen Sie eine Factory-Methode zur Erstellung, damit Sie Ihre Klasse testen können, ohne den Singleton zu verwenden.Wenn sich das als problematisch erweist oder Ihr Singleton einen veränderlichen Zustand hat (ich hätte davor Angst, aber hey, das bin ich), dann versuchen Sie, ihn so zu gestalten, dass Ihr Singleton so einfach wie möglich in Ihre Tests integriert werden kann.

Sie möchten nicht eine komplette Konfigurationsdatei erstellen müssen, nur um eine Methode für eine Klasse zu testen, die die Standardabweichung eines Blocks von Aktienkursen über einen Zeitraum von 4 Stunden berechnet.Das ist zu viel Arbeit.Aber wenn Ihr Singleton so geschrieben ist, dass Sie ihn mit den Daten füllen können und eine andere Klasse für das Einlesen der Konfigurationsdatei und das Auffüllen dieser Daten verantwortlich ist, dann haben Sie große Fortschritte gemacht.

In Bezug auf statische Methoden würde ich behaupten, dass sie die am einfachsten zu testenden Methoden sind, die Sie schreiben können, vorausgesetzt, Sie müssen sich keine Gedanken über den globalen Status machen.Statisch sind äquivalent zu y = f(x) Dies erscheint simpel, liegt aber der Tatsache zugrunde, dass keine lokalen Zustandsübergänge die Invariante „das“ für einen gegebenen Zustand ändern können x Du wirst immer das Gleiche bekommen y.

Answer 3

Wie bei jeder Software-Engineering-Praxis gibt es niemals eine endgültige Lösung für jede Situation.Sie sollten also niemals statische Methoden, statische Klassen und Singletons ausschließen.Das Ziel von TDD ist es, Ihr Leben einfacher zu gestalten, und Sie werden feststellen, dass Sie, wenn Sie mehr mit TDD arbeiten, Ihr Code modular ist, was bedeutet, dass auch wenn Sie statische Methoden (... usw.) verwenden. Ihr Code wird immer noch destilliert.

Regel, die ich gerne live von Is: Verwenden Sie alles, was Sie möchten, solange Ihr Code leicht lesbar ist und Ihr Design elegant ist.Wie Sie diese erreichen 2, liegt bei Ihnen.HECK Sie können auch Gotos verwenden, wenn Sie immer noch elegantem Code liefern können.

Answer 4

Ich habe diese statischen Methoden gelesen ... sind böse, wenn Sie versuchen, das Gerätestest zu implementieren

Ich habe das noch nie gelesen. Könnten Sie eine Referenz anbieten? Und ich würde es bestreiten. Ich verwende und testen statische Methoden (Funktionen) und problemlos.

---

bearbeitet

Vielen Dank für den Verweis auf static Methoden sind Tod für Testability : Dieser Artikel ist Müll.

Das grundlegende Problem mit statischen Methoden ist ein Verfahrenscode. Ich habe keine Ahnung, wie man den Prozedurcode einheitert.

Dies zeigt an, dass der AUTOR nicht viel über die Untersuchungstests weiß. Natürlich können Sie den Prozedurcode testen.

Während der Instantiierung drücke ich die Abhängigkeiten mit Mocks / Freundschaften, die die echten Abhängigkeiten ersetzen.

Dies ist der Schlüsselfehler: Die Idee, dass das Gerät testet erfordert scheinobjekte. Es tut nicht. In jedem Fall können Sie die Mock-Objekte als Argumente an die statische Methode bestehen, die Sie testen: Die Abhängigkeitseinspritzung erfordert keinen Konstruktor. Weitere Informationen finden Sie in die akzeptierte Antwort der Frage "statische Methoden: wann und wann nicht "

Wenn die statische Methode eine andere statische Methode aufruft, gibt es keine Möglichkeit, die genannte Methodeabhängigkeit zu überschreiten.

wahr, aber irrelevant. Wenn statische Methode a aufrufe statische Methode b , das ist ein -Animplementierungsdetail des Verfahrens a . Sie haben also kein Geschäft probieren , um den Anruf an b abzufangen. Behandeln Sie einfach a als Einheit.

Angenommen, Ihre Anwendung hat nichts als statische Methoden

ein Strawman-Argument. Im Kontext der modernen Untertestung sprechen wir eindeutig über ein OO-Programm mit nur einigen statischen Methoden.