Ist statisch für Unit-Tests allgemein „böse“ und wenn ja, warum empfiehlt Resharper es? [geschlossen]

85

Ich habe festgestellt, dass es in C # .NET nur drei Möglichkeiten zum Testen von Einheiten (Mock / Stub) gibt:

Angesichts der Tatsache, dass zwei davon nicht kostenlos sind und einer Release 1.0 noch nicht erreicht hat, ist es nicht einfach, statische Inhalte zu verspotten.

Macht das statische Methoden und solche "bösen" (im Sinne von Unit-Tests)? Und wenn ja, warum möchte Resharper, dass ich alles herstelle, was statisch oder statisch sein kann? (Vorausgesetzt, Resharper ist nicht auch "böse".)

Erläuterung: Ich spreche von dem Szenario, in dem Sie eine Methode einem Komponententest unterziehen möchten und diese Methode eine statische Methode in einer anderen Einheit / Klasse aufruft . Wenn Sie nach den meisten Definitionen des Komponententests die getestete Methode nur die statische Methode in der anderen Einheit / Klasse aufrufen lassen, dann sind Sie kein Komponententest, sondern ein Integrationstest . (Nützlich, aber kein Komponententest.)

Vaccano
quelle
3
TheLQ: Sie können. Ich glaube, er spricht davon, statische Methoden nicht testen zu können, weil sie häufig statische Variablen berühren. Somit ändert sich der Zustand nach und zwischen Test.
26
Persönlich denke ich, dass Sie die Definition von "Einheit" zu weit gehen. "Einheit" sollte "kleinste Einheit sein, die sinnvoll ist, isoliert zu testen". Das kann eine Methode sein, es kann mehr sein. Wenn die statische Methode keinen Status hat und gut getestet wurde, ist ein zweiter Unit-Test-Aufruf (IMO) kein Problem.
mlk
10
"Persönlich denke ich, dass Sie die Definition von" Einheit "zu weit gehen." Nein, es ist nur so, dass er den Standardgebrauch verwendet und Sie sich Ihre eigene Definition ausdenken.
7
"Warum möchte Resharper, dass ich alles herstelle, was statisch und statisch sein kann?" Resharper möchte nicht, dass Sie etwas tun. Es macht Sie lediglich darauf aufmerksam, dass die Modifikation bei einer Code-Analyse-POV möglich und möglicherweise wünschenswert ist. Resharper ist kein Ersatz für Ihr eigenes Urteilsvermögen!
Adam Naylor
4
@ acidzombie24. Regelmäßige Methoden können auch den statischen Status ändern, sodass sie genauso "schlecht" sind wie statische Methoden. Die Tatsache, dass sie den Zustand auch mit einem kürzeren Lebenszyklus ändern können, macht sie noch gefährlicher. (Ich bin nicht für statische Methoden, aber der Punkt über Zustandsänderung ist auch ein Schlag gegen reguläre Methoden, umso mehr)
mike30

Antworten:

105

Wenn ich mir die anderen Antworten hier anschaue, kann es zu Verwirrungen kommen zwischen statischen Methoden, die einen statischen Zustand aufweisen oder Nebenwirkungen verursachen (was für mich nach einer wirklich schlechten Idee klingt), und statischen Methoden, die lediglich einen Wert zurückgeben.

Statische Methoden, die keinen Zustand haben und keine Nebenwirkungen hervorrufen, sollten leicht in der Einheit testbar sein. Tatsächlich betrachte ich solche Methoden als eine "arme" Form der funktionalen Programmierung; Sie übergeben der Methode ein Objekt oder einen Wert und sie gibt ein Objekt oder einen Wert zurück. Nichts mehr. Ich verstehe nicht, wie sich solche Methoden überhaupt negativ auf das Testen von Einheiten auswirken würden.

Robert Harvey
quelle
44
Die statische Methode kann in Einheiten getestet werden, aber wie sieht es mit den Methoden aus, die die statische Methode aufrufen? Wenn die Anrufer einer anderen Klasse angehören, besteht eine Abhängigkeit, die für einen Komponententest entkoppelt werden muss.
Vaccano
22
@Vaccano: Wenn Sie jedoch statische Methoden schreiben, die den Status nicht halten und keine Nebenwirkungen haben, entsprechen sie mehr oder weniger der Funktionalität eines Stubs.
Robert Harvey
20
Einfache vielleicht. Komplexere können jedoch Ausnahmen auslösen und Ausgaben haben, die nicht erwartet werden (und sollten im Unit-Test für die statische Methode, nicht im Unit-Test für den Aufrufer der statischen Methode abgefangen werden), oder zumindest das ist, was ich wurden dazu gebracht, an die Literatur zu glauben, die ich gelesen habe.
Vaccano
21
@Vaccano: Eine statische Methode mit Ausgaben oder zufälligen Ausnahmen hat Nebenwirkungen.
Tikhon Jelvis
10
@TikhonJelvis Robert wurde im Gespräch über Ausgänge; und "zufällige" Ausnahmen sollten keine Nebenwirkung sein, sie sind im Wesentlichen eine Form der Ausgabe. Der Punkt ist, dass Sie beim Testen einer Methode, die die statische Methode aufruft, diese Methode und alle Permutationen ihrer potenziellen Ausgabe umschließen und Ihre Methode nicht isoliert testen können.
Nicole
26

Sie scheinen statische Daten und statische Methoden zu verwechseln . Wenn ich mich recht erinnere, empfiehlt Resharper, privateMethoden innerhalb einer Klasse statisch zu machen, wenn dies möglich ist. Ich glaube, dies bringt einen kleinen Leistungsvorteil. Es wird nicht empfohlen, "alles, was sein kann", statisch zu machen!

An statischen Methoden ist nichts auszusetzen, und sie sind einfach zu testen (solange sie keine statischen Daten ändern). Stellen Sie sich zum Beispiel eine Mathematikbibliothek vor, die sich gut für eine statische Klasse mit statischen Methoden eignet. Wenn Sie eine (erfundene) Methode wie diese haben:

public static long Square(int x)
{
    return x * x;
}

dann ist dies hervorragend testbar und hat keine Nebenwirkungen. Sie müssen nur überprüfen, ob Sie nach dem Eintreffen von beispielsweise 20 400 zurückerhalten. Kein Problem.

Dan Diplo
quelle
4
Was passiert, wenn Sie eine andere Klasse haben, die diese statische Methode aufruft? Scheint in diesem Fall einfach, aber es ist eine Abhängigkeit, die nur mit einem der drei oben aufgeführten Tools isoliert werden kann. Wenn Sie es nicht isolieren, dann sind Sie kein "Unit-Test", sondern ein "Integrationstest" (weil Sie testen, wie gut sich Ihre verschiedenen Einheiten "integrieren").
Vaccano
3
Nichts passiert. Warum sollte es? Das .NET Framework ist voll von statischen Methoden. Wollen Sie damit sagen, dass Sie diese Methoden auch nicht für Unit-Tests verwenden können?
Dan Diplo
3
Wenn Ihr Code der Produktionsstufe / -qualität von .NET Framework entspricht, fahren Sie fort. Der springende Punkt beim Testen von Einheiten ist jedoch, die Einheit für sich zu testen. Wenn Sie Methoden auch in anderen Units aufrufen (statische oder sonstige), testen Sie jetzt Ihre Unit und ihre Abhängigkeiten. Ich sage nicht, dass es kein nützlicher Test ist, aber nach den meisten Definitionen kein "Komponententest". (Weil Sie jetzt Ihr zu testendes Gerät und das Gerät mit der statischen Methode testen).
Vaccano
10
Vermutlich haben Sie (oder andere) die statische Methode bereits getestet und gezeigt, dass sie (zumindest wie erwartet) funktioniert, bevor Sie zu viel Code um sie herum schreiben. Wenn bei dem Teil, den Sie als nächstes testen, etwas kaputt geht, sollten Sie zuerst nachsehen, nicht nach dem, was Sie bereits getestet haben.
cHao
6
@Vaccano Wie testet Microsoft dann das .NET Framework? Viele der Klassen im Framework verweisen auf statische Methoden in anderen Klassen (z. B. System.Math), ganz zu schweigen von der Fülle der statischen Factory-Methoden usw. Außerdem könnten Sie niemals Erweiterungsmethoden usw. verwenden. Tatsache ist, dass dies einfache Funktionen sind grundlegend für moderne Sprachen. Sie können diese isoliert testen (da sie im Allgemeinen deterministisch sind) und sie dann problemlos in Ihren Klassen verwenden. Es ist kein Problem!
Dan Diplo
18

Wenn die eigentliche Frage hier lautet: "Wie teste ich diesen Code?":

public class MyClass
{
   public void MethodToTest()
   {
       //... do something
       MyStaticClass.StaticMethod();
       //...more
   }
}

Dann überarbeiten Sie einfach den Code und fügen wie gewohnt den folgenden Aufruf an die statische Klasse ein:

public class MyClass
{
   private readonly IExecutor _externalExecutor;
   public MyClass(_IExecutor executor)
   {
       _exeternalExecutor = executor;
   }

   public void MethodToTest()
   {
       //... do something
       _exetrnalExecutor.DoWork();
       //...more
   }
}

public class MyStaticClassExecutor : IExecutor
{
    public void DoWork()
    {
        MyStaticClass.StaticMethod();
    }
}
Sonnig
quelle
9
Zum Glück haben wir auch Fragen zur Code-Lesbarkeit und zu KISS on SO :)
gbjbaanb
Wäre ein Delegierter nicht einfacher und würde das Gleiche tun?
jk.
@jk könnte sein, aber es ist dann schwierig, einen IoC-Container zu verwenden.
Sunny
15

Statik ist nicht unbedingt böse, aber sie kann Ihre Möglichkeiten einschränken, wenn es um Unit-Tests mit Fakes / Mocks / Stubs geht.

Es gibt zwei allgemeine Herangehensweisen an das Verspotten.

Die erste (traditionell von RhinoMocks, Moq, NMock2 implementierte; manuelle Mocks und Stubs sind auch in diesem Lager vorhanden) basiert auf Testnähten und Abhängigkeitsinjektion. Angenommen, Sie testen einen statischen Code in einer Einheit und er weist Abhängigkeiten auf. Was im Code geschieht oft so gestaltet ist , dass Statik ihre eigenen Abhängigkeiten schaffen, Invertierung Abhängigkeit Inversion . Sie werden schnell feststellen, dass Sie in den so gestalteten Testcode keine gespielten Schnittstellen einfügen können.

Die zweite (Mock-Funktion - implementiert von TypeMock, JustMock und Moles) basiert auf der .NET- Profiling-API . Es kann alle Ihre CIL-Anweisungen abfangen und einen Teil Ihres Codes durch eine Fälschung ersetzen. Dadurch können TypeMock und andere Produkte in diesem Camp alles verspotten: Statik, versiegelte Klassen, private Methoden - Dinge, die nicht testbar sind.

Es gibt eine anhaltende Debatte zwischen zwei Denkschulen. Man sagt, folgen Sie SOLID Prinzipien und Design für Testbarkeit (das beinhaltet oft schonende Statik). Der andere sagt, kaufe TypeMock und mach dir keine Sorgen.

Azheglov
quelle
14

Überprüfen Sie dies: "Statische Methoden sind der Tod für die Testbarkeit" . Kurze Zusammenfassung des Arguments:

Zum Komponententest müssen Sie einen kleinen Teil Ihres Codes nehmen, seine Abhängigkeiten neu verkabeln und ihn isoliert testen. Dies ist bei statischen Methoden schwierig, nicht nur, wenn sie auf den globalen Status zugreifen, sondern auch, wenn sie nur andere statische Methoden aufrufen.

Rafał Dowgird
quelle
32
Ich behalte den globalen Status nicht bei und verursache keine Nebenwirkungen bei meinen statischen Methoden. Daher scheint mir dieses Argument irrelevant zu sein. In dem Artikel, den Sie verlinkt haben, wird ein Slippery-Slope-Argument angegeben, das keine Grundlage hat, wenn statische Methoden auf einfachen prozeduralen Code beschränkt sind und "generisch" wirken (wie mathematische Funktionen).
Robert Harvey
4
@Robert Harvey - wie testet man eine Methode, die eine statische Methode einer anderen Klasse verwendet (dh von einer statischen Methode abhängig ist)? Wenn Sie es einfach so nennen lassen, dann sind Sie kein "Unit-Test", sondern ein "Integrationstest"
Vaccano
10
Lesen Sie nicht nur den Blog-Artikel, sondern auch die vielen Kommentare, die damit nicht einverstanden sind. Ein Blog ist nur eine Meinung, keine Tatsache.
Dan Diplo
8
@Vaccano: Eine statische Methode ohne Nebenwirkungen oder externen Zustand entspricht funktionell einem Wert. Wenn Sie das wissen, ist es nichts anderes als Unit-Tests einer Methode, die eine Ganzzahl erzeugt. Dies ist eine der wichtigsten Erkenntnisse, die uns die funktionale Programmierung gibt.
Steven Evers
3
Wenn eingebettete Systeme nicht funktionieren oder eine App, deren Fehler das Potenzial haben, internationale Vorfälle auszulösen, hat IMO, als "Testbarkeit" die Architektur vorantreibt, alles verdreht, bevor Sie überhaupt Test-Every-Last-Corner-Methoden eingeführt haben. Außerdem habe ich es satt, dass XP alles beherrscht, was jedes Gespräch dominiert. XP ist keine Autorität, es ist eine Industrie. Hier ist die ursprüngliche, vernünftige Definition von Unit Testing: python.net/crew/tbryan/UnitTestTalk/slide2.html
Erik Reppen
5

Die einfache Wahrheit, die selten anerkannt wird, ist, dass eine Klasse, die eine vom Compiler sichtbare Abhängigkeit von einer anderen Klasse enthält, nicht isoliert von dieser Klasse getestet werden kann . Sie können etwas vortäuschen, das wie ein Test aussieht und in einem Bericht so angezeigt wird, als wäre es ein Test.

Der Schlüssel, der die Eigenschaften eines Tests definiert, ist jedoch nicht vorhanden. Scheitern, wenn Dinge falsch sind, vergehen, wenn sie richtig sind.

Dies gilt für alle statischen Aufrufe, Konstruktoraufrufe und Verweise auf Methoden oder Felder, die nicht von einer Basisklasse oder Schnittstelle geerbt wurden . Wenn der Klassenname im Code angezeigt wird, handelt es sich um eine vom Compiler sichtbare Abhängigkeit, ohne die Sie keine gültigen Tests durchführen können. Ein kleinerer Block ist einfach keine gültige prüfbare Einheit . Jeder Versuch, es so zu behandeln, als wäre es ein Ergebnis, das nicht aussagekräftiger ist, als ein kleines Hilfsprogramm zu schreiben, das das XML ausgibt, das von Ihrem Testframework verwendet wird, um zu sagen, dass der Test bestanden wurde.

Vor diesem Hintergrund gibt es drei Möglichkeiten:

  1. Definieren Sie Unit-Tests als Tests der Unit, die aus einer Klasse und ihren fest codierten Abhängigkeiten besteht. Dies funktioniert, sofern Sie kreisförmige Abhängigkeiten vermeiden.

  2. Erstellen Sie niemals Abhängigkeiten zur Kompilierungszeit zwischen Klassen, für die Sie verantwortlich sind. Dies funktioniert, vorausgesetzt, Sie haben nichts gegen den resultierenden Codestil.

  3. Nicht Unit-Test, sondern Integrationstest. Was funktioniert, vorausgesetzt, es steht in keinem Konflikt mit etwas anderem, für das Sie den Begriff Integrationstest verwenden müssen.

Soru
quelle
3
Es gibt nichts, was besagt, dass ein Komponententest ein Test für eine einzelne Klasse ist. Es ist ein Test einer einzelnen Einheit. Unit-Tests zeichnen sich dadurch aus, dass sie schnell, wiederholbar und unabhängig sind. Das Referenzieren Math.Piin einer Methode macht sie nach keiner vernünftigen Definition zu einem Integrationstest.
Sara
Ich stimme zu, dass dies der beste Ansatz ist, aber es kann nützlich sein, zu wissen, dass andere Leute die Begriffe anders verwenden (vernünftigerweise oder nicht).
soru
4

Es gibt keine zwei Möglichkeiten. Die Vorschläge von ReSharper und einige nützliche Funktionen von C # würden nicht so häufig verwendet, wenn Sie isolierte Atom-Unit-Tests für Ihren gesamten Code schreiben würden.

Wenn Sie zum Beispiel über eine statische Methode verfügen und diese entfernen müssen, können Sie dies nur tun, wenn Sie ein profilbasiertes Isolationsframework verwenden. Eine aufrufkompatible Problemumgehung besteht darin, den oberen Rand der Methode so zu ändern, dass die Lambda-Notation verwendet wird. Zum Beispiel:

VOR:

    public static DBConnection ConnectToDB( string dbName, string connectionInfo ) {
    }

NACH:

    public static Func<string, string, DBConnection> ConnectToDB (dbName, connectionInfo ) {
    };

Die beiden sind anrufkompatibel. Anrufer müssen sich nicht ändern. Der Körper der Funktion bleibt der gleiche.

Dann können Sie in Ihrem Unit-Test-Code diesen Aufruf wie folgt stoppen (vorausgesetzt, er befindet sich in einer Klasse namens Database):

        Database.ConnectToDB = (dbName, connectionInfo) => { return null|whatever; }

Ersetzen Sie es nach Beendigung des Vorgangs durch den ursprünglichen Wert. Sie können dies über einen try / finally-Befehl tun oder in Ihrer Unit-Test-Bereinigung den Code eingeben, der nach jedem Test aufgerufen wird:

    [TestCleanup]
    public void Cleanup()
    {
        typeof(Database).TypeInitializer.Invoke(null, null);
    }

Dadurch wird der statische Initialisierer Ihrer Klasse erneut aufgerufen.

Lambda-Funcs sind nicht so unterstützend wie normale statische Methoden, daher hat dieser Ansatz die folgenden unerwünschten Nebenwirkungen:

  1. Wenn es sich bei der statischen Methode um eine Erweiterungsmethode handelte, müssen Sie diese zuerst in eine Nicht-Erweiterungsmethode ändern. Resharper kann dies automatisch für Sie tun.
  2. Wenn einer der Datentypen der statischen Methoden eine eingebettete Interop-Assembly ist, z. B. für Office, müssen Sie die Methode umbrechen, den Typ umbrechen oder in den Typ 'object' ändern.
  3. Sie können das Refactoring-Tool für Signaturänderungen von Resharper nicht mehr verwenden.

Nehmen wir jedoch an, Sie vermeiden die Statik vollständig und konvertieren sie in eine Instanzmethode. Es ist immer noch nicht verspottbar, es sei denn, die Methode ist entweder virtuell oder als Teil einer Schnittstelle implementiert.

In Wirklichkeit ist jeder, der die Lösung für das Stubben statischer Methoden vorschlägt, sie zu Instanzmethoden zu machen, auch gegen Instanzmethoden, die nicht virtuell oder Teil einer Schnittstelle sind.

Warum verfügt C # über statische Methoden? Warum sind nicht virtuelle Instanzmethoden zulässig?

Wenn Sie eine dieser "Funktionen" verwenden, können Sie einfach keine isolierten Methoden erstellen.

Also wann benutzt du sie?

Verwenden Sie sie für jeden Code, von dem Sie nicht erwarten, dass er jemals veröffentlicht werden soll. Einige Beispiele: Die Format () -Methode der String-Klasse Die WriteLine () -Methode der Console-Klasse Die Cosh () -Methode der Math-Klasse

Und noch etwas. Die meisten Leute interessieren sich nicht dafür, aber wenn Sie die Leistung eines indirekten Aufrufs beurteilen können, ist dies ein weiterer Grund, Instanzmethoden zu vermeiden. Es gibt Fälle, in denen die Leistung beeinträchtigt wird. Deshalb gibt es in erster Linie nicht-virtuelle Methoden.

Zumalifeguard
quelle
3
  1. Ich glaube, es liegt zum Teil daran, dass statische Methoden "schneller" aufzurufen sind als Instanzmethoden. (In Anführungszeichen, weil dies nach Mikrooptimierung riecht) siehe http://dotnetperls.com/static-method
  2. Es sagt Ihnen, dass es keinen Status benötigt und daher von überall aufgerufen werden kann, wodurch der Aufwand für die Initiierung beseitigt wird, wenn dies das einzige ist, was jemand benötigt.
  3. Wenn ich es verspotten möchte, dann denke ich, dass es im Allgemeinen die Praxis ist, dass es auf einer Schnittstelle deklariert wird.
  4. Wenn es auf einer Schnittstelle deklariert ist, wird R # nicht vorschlagen, dass Sie es statisch machen.
  5. Wenn es als virtuell deklariert ist, schlägt R # auch nicht vor, es statisch zu machen.
  6. Das statische Halten von Zuständen (Feldern) sollte immer sorgfältig abgewogen werden . Statischer Zustand und Gewinde vermischen sich wie Lithium und Wasser.

R # ist nicht das einzige Tool, das diesen Vorschlag macht. Die FxCop / MS-Code-Analyse macht dasselbe.

Ich würde allgemein sagen, dass wenn die Methode statisch ist, sie im Allgemeinen auch testbar sein sollte. Das bringt einige Überlegungen zum Design und wahrscheinlich mehr Diskussionen mit sich, als ich gerade in meinen Fingern habe. Warten Sie also geduldig auf die Abstimmungen und Kommentare ...;)

MIA
quelle
Können Sie eine statische Methode / ein statisches Objekt für eine Schnittstelle deklarieren? (Das glaube ich nicht). Ich beziehe mich übrigens darauf, wenn Ihre statische Methode von der zu testenden Methode aufgerufen wird. Befindet sich der Anrufer in einer anderen Einheit, muss die statische Methode isoliert werden. Dies ist mit einem der drei oben aufgeführten Tools nur sehr schwer möglich.
Vaccano
1
Nein, Sie können keine statischen Werte für eine Schnittstelle deklarieren. Es wäre sinnlos.
MIA,
3

Ich sehe, dass nach langer Zeit noch niemand eine wirklich einfache Tatsache festgestellt hat. Wenn der Resharper mir sagt, dass ich eine Methode statisch machen kann, bedeutet das eine große Sache für mich. Ich kann seine Stimme sagen: "Hey, Sie, diese logischen Teile sind nicht die VERANTWORTUNG der aktuellen Klasse, also sollte sie draußen bleiben in irgendeiner Helferklasse oder so ".

g1ga
quelle
2
Ich stimme dir nicht zu. Meistens, wenn Resharper sagt, dass ich etwas Statisches machen kann, ist es ein bisschen Code, der zwei oder mehr Methoden in der Klasse gemeinsam hat, und deshalb habe ich ihn zu einer eigenen Prozedur extrahiert. Das auf einen Helfer zu übertragen, wäre bedeutungslos kompliziert.
Loren Pechtel
2
Ich kann Ihren Standpunkt nur sehen, wenn die Domain sehr einfach ist und sich nicht für zukünftige Änderungen eignet. Was Sie als "bedeutungslose Komplexität" bezeichnen, ist für mich ein gutes und für den Menschen lesbares Design. Eine Helferklasse mit einfachen und eindeutigen Gründen zu haben, ist in gewisser Weise das "Mantra" der Prinzipien von SoC und Single Responsibility. In Anbetracht der Tatsache, dass diese neue Klasse zu einer Abhängigkeit für die Hauptklasse wird, müssen einige öffentliche Mitglieder entlarvt werden, und als natürliche Konsequenz kann sie isoliert getestet und leicht verspottet werden, wenn sie als Abhängigkeit fungiert.
g1ga
1
Für die Frage nicht relevant.
Igby Largeman
2

Wenn die statische Methode von einer anderen Methode aus aufgerufen wird , ist es nicht möglich, einen solchen Aufruf zu verhindern oder zu ersetzen. Dies bedeutet, dass diese beiden Methoden eine einzige Einheit bilden. Unit-Test jeder Art testet sie beide.

Und wenn diese statische Methode mit dem Internet kommuniziert, Datenbanken verbindet, GUI-Popups anzeigt oder den Unit-Test auf andere Weise in ein vollständiges Durcheinander umwandelt, ist keine leichte Umgehung erforderlich. Eine Methode, die eine solche statische Methode aufruft, kann nicht ohne Refactoring getestet werden, selbst wenn sie eine Menge reinen Berechnungscodes enthält, für die ein Unit-Test von großem Vorteil wäre.

h22
quelle
0

Ich glaube, dass Resharper Ihnen Anhaltspunkte gibt und Sie die Kodierungsrichtlinien anwenden, mit denen es eingerichtet wurde. Wenn ich Resharper verwendet habe und festgestellt habe, dass eine Methode statisch sein sollte, muss sie sich in einer privaten Methode befinden, die keine Instanzvariablen verarbeitet.

Was nun die Testbarkeit betrifft, sollte dieses Szenario kein Problem darstellen, da Sie private Methoden sowieso nicht testen sollten.

In Bezug auf die Testbarkeit von statischen Methoden, die öffentlich sind, wird das Testen von Einheiten schwierig, wenn statische Methoden den statischen Zustand berühren. Persönlich würde ich dies auf ein Minimum beschränken und statische Methoden so weit wie möglich als reine Funktionen verwenden, bei denen Abhängigkeiten in die Methode übertragen werden, die über eine Testvorrichtung gesteuert werden können. Dies ist jedoch eine Entwurfsentscheidung.

aqwert
quelle
Ich beziehe mich auf, wenn Sie eine Methode im Test haben (nicht statisch), die eine statische Methode in einer anderen Klasse aufruft. Diese Abhängigkeit kann nur mit einem der drei oben aufgeführten Tools isoliert werden. Wenn Sie es nicht isolieren, handelt es sich um einen Integrationstest, nicht um einen Komponententest.
Vaccano
Der systeminterne Zugriff auf Instanzvariablen kann nicht statisch sein. Der einzige Zustand, den eine statische Methode möglicherweise haben kann, sind Klassenvariablen. Der einzige Grund, der auftreten sollte, ist, dass Sie mit einem Singleton arbeiten und daher keine Wahl haben.
Loren Pechtel