jmock eine statische Methode verspotten

Question

Ich habe eine statische Methode in meinem Code, die ich irgendwie zu verspotten möchte.

Ich benutze jmock.

Eine Möglichkeit, ich könnte dies tun, ist "Wrapper-Klasse" um die statische Methode und Mock dies haben, aber ich hatte auf eine bessere Lösung gehofft.

Ich gehe das in die falsche Richtung?

FEEDBACK:

Ich wollte eine Schnittstelle und Klasse haben, die eine Methode hatte, die nur die statische Methode aufgerufen. Es würde mir erlauben, die Logik zu verspotten, indem ich nur den Aufruf dieser Wrapper-Klasse verspottete. (Ich fühle mich dreckig sogar darüber zu reden :))

Answer 1

Wir unterstützen keine spöttischen statischen Methoden in jMock, weil es nicht unserem Designansatz entspricht. Wir bevorzugen, keine statischen Methoden für signifikante Funktionen zu verwenden, die den Systemzustand beeinflussen können. Wir neigen dazu, sie nur zu verwenden, um den OO-Code zu unterstützen und ihn lesbarer zu machen. Aus diesem Grund betrachten wir statische Methoden als Hinweis, dass ein Problem vorliegt. Eine Ausnahme ist, wo es in einer Drittanbieter-Bibliothek ist, aber wir würden das wahrscheinlich in etwas Objektorientiertes einbetten.

Answer 2

Powermock ist eine Erweiterung zu EasyMock, die das Spotten von statischen Methoden ermöglicht.

Answer 3

JMockit ist ein weiteres Toolkit, das das Mocking von statischen Methoden (sowie von finalen Methoden, Konstruktoren usw.) ermöglicht.

Ich sehe kein Problem mit der vernünftigen Verwendung von statischen Methoden beim Entwurf einer anderen OO-Lösung.

Zum Beispiel, ein Muster/Idiom, das ich gerne verwenden möchte, ist die statische Fassade, insbesondere um eine einfachere und benutzerfreundlichere API für das Persistenz-Subsystem in einer Geschäftsanwendung zu bieten. Meiner Meinung nach, ist keine andere Lösung eleganter als so etwas wie:

    List<Person> peopleAboveAge = 
     find("select p from Person p where p.age >= ?", age); 

wo die find Methode aus einer PersistenceFacade Klasse statisch importiert wird, die nur statische Methoden definiert, und kapselt, wie die richtige Session/EntityManager-Instanz zu erhalten. Diese Lösung ist Unit-Testing-freundlich und flexibel. Ich habe es in einer Geschäftsanwendung verwendet, die mehr als 500 dauerhafte Entitäten mit Hibernate verwendet. Die statische Fassade half bei der Migration von Hibernate 2 zu Hibernate 3, als wir von Oracle zu Sybase und dann zurück zu Oracle migrierten, und als wir anfingen, JPA-Annotationen anstelle von "hbm.xml" -Dateien für das ORM-Mapping zu verwenden.