Ich bin neu bei TDD und DDD und habe eine einfache Frage zu statischen Methoden im Allgemeinen. Die meisten TDD-Gurus sagen mit einem Wort, dass statische Methoden schlecht sind (und dass wir vergessen sollten, Tonnen von statischen Dienstprogrammen zu erzeugen, die wir (um oder ich) früher benutzt haben, da sie nicht überprüfbar sind. Ich kann sehen, warum sie sind) nicht überprüfbar (ein großer Artikel zur Klärung findet sich hier hier ) diejenigen, die interessiert sind, aber ich denke, ich bin der einzige Neuling hier :(), aber ich frage mich, gibt es eine schöne und saubere Richtlinie für die Verwendung von Statik aus TDD Sicht?
Das mag für die meisten von euch eine sehr dumme Frage sein, aber einige Tipps wären großartig und ich möchte nur wissen, wie Experten hier über statische Dinge denken. Danke im Voraus.
Edit: Während ich nach Antwort suchte, fand ich zwei andere nette Threads bezüglich der Verwendung von statischen (nicht TDD Bedenken), die ich denke, sind gute Reads für diejenigen, die interessiert sind (mich inklusive).
Ich denke, Sie haben vielleicht etwas missverstanden.
Statische Methoden sind testbar. Nehmen Sie diese Methode als Beispiel:
%Vor%Sie können dies testen, indem Sie testen, ob der Rückgabewert basierend auf den übergebenen Argumenten den Erwartungen entspricht.
Wo statische Methoden beim Testen problematisch werden, wenn Sie einen Schein einführen müssen.
Nehmen wir an, ich habe Code, der die statische Methode File.Delete() aufruft. Um meinen Code zu testen, ohne mich auf das Dateisystem zu verlassen, möchte ich diesen Aufruf durch eine Testversion ersetzen / nachahmen, die lediglich bestätigt, dass sie aus dem getesteten Code aufgerufen wurde. Dies ist einfach, wenn ich eine Instanz eines Objekts hatte, auf dem Delete() aufgerufen wurde. Die meisten (alle?) Spionage-Frameworks können statische Methoden nicht vortäuschen, daher zwingt mich eine statische Methode in meinem Code, sie anders zu testen (normalerweise durch Aufruf der echten statischen Methode).
Um so etwas zu testen, würde ich eine Schnittstelle einführen:
%Vor% Mein Code würde dann eine Instanz eines Objekts nehmen, das diese Schnittstelle implementiert (entweder im Methodenaufruf oder als Parameter im Konstruktor) und dann seine Methode Delete() aufrufen, um das Löschen auszuführen:
Um das zu testen, kann ich die IFileDeleter -Schnittstelle überspielen und einfach überprüfen, ob ihre Delete() -Methode aufgerufen wurde. Dies macht die Verwendung eines echten Dateisystems als Teil des Tests überflüssig.
Das sieht vielleicht so aus, als ob der Code komplexer ist (was er ist), aber es macht sich bezahlt, dass es viel einfacher ist, ihn zu testen.
Die Vermeidung von Statik ist sicherlich der richtige Weg. Wenn Sie jedoch nicht mit Legacy-Code arbeiten können, ist die folgende Option verfügbar. Nach der obigen Antwort von adrianbanks nehmen wir an, Sie haben den folgenden Code (Entschuldigung, in Java, da ich C # nicht kenne):
%Vor%Sie können die Datei.delete () in ihre eigene Methode wie folgt umgestalten:
%Vor%und dann in Vorbereitung auf deinen Komponententest eine Mock-Klasse erstellen, die das Original erweitert und diese Funktionalität ausfüllt:
%Vor%und schließlich in Ihrem Komponententest:
%Vor%Nun haben Sie alle Funktionen von someMethod () ausgeführt, ohne die Datei tatsächlich zu löschen, und Sie können immer noch sehen, ob diese Methode aufgerufen wurde.
Im Allgemeinen, wenn die Methode:
Vermeiden Sie es, es statisch zu machen. (Siehe die Antwort von @adrianbanks für eine ausgezeichnete Diskussion der Gründe und der Alternativen.)
Im Grunde genommen sollte es nur statisch gemacht werden, wenn es sich um eine kurze In-Memory-Komfortmethode handelt (wie viele Erweiterungsmethoden).
Tags und Links .net tdd domain-driven-design