jmock se moquer d'une méthode statique

Question

J'ai une méthode statique dans mon code que je voudrais en quelque sorte se moquer.

J'utilise jmock.

Une façon que je suppose que je pourrais faire ceci est d'avoir "wrapper class" autour de la méthode statique et se moquer de cela, mais j'espérais une meilleure solution.

Je vais à ce sujet dans le mauvais sens?

COMMENTAIRES:

J'allais avoir une interface et la classe qui avait une méthode qui vient d'appeler la méthode statique. Cela me permettrait de se moquer de la logique en se moquant simplement de l'appel à cette classe de wrapper. (Je me sens sale même en parler :))

Answer 1

Nous ne prenons pas en charge les méthodes statiques moqueuses dans jMock car elles ne correspondent pas à notre approche de conception. Nous préférons ne pas utiliser de méthodes statiques pour les fonctionnalités importantes qui peuvent affecter l'état du système. Nous avons tendance à les utiliser uniquement pour soutenir le code OO et le rendre plus lisible. C'est pourquoi nous considérons les méthodes statiques comme une indication qu'il y a un problème. Une exception est l'endroit où il se trouve dans une bibliothèque tierce, mais nous l'inclurions probablement dans quelque chose de plus orienté objet.

Answer 2

Powermock est une extension à EasyMock qui permet de se moquer des méthodes statiques.

Answer 3

JMockit est une autre boîte à outils qui permet de se moquer des méthodes statiques (ainsi que des méthodes finales, des constructeurs, etc.).

Je ne vois aucun problème avec le judicieux l'utilisation de méthodes statiques lors de la conception d'une solution autrement OO. Par exemple, un motif/idiome que j'aime utiliser est la façade statique , en particulier pour fournir une API plus simple et plus facile à utiliser pour le sous-système de persistance dans une application métier. À mon avis, aucune autre solution est plus élégante que quelque chose comme:

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

où la méthode find est importée statiquement d'une classe PersistenceFacade qui ne définit que des méthodes statiques et encapsule comment obtenir la bonne instance de session/EntityManager. Cette solution est conviviale et flexible. Je l'ai utilisé dans une application d'entreprise qui avait plus de 500 entités persistantes, en utilisant Hibernate. La façade statique a aidé lorsque nous avons migré d'Hibernate 2 vers Hibernate 3, lorsque nous avons migré d'Oracle vers Sybase puis de nouveau vers Oracle, et lorsque nous avons commencé à utiliser les annotations JPA au lieu des fichiers "hbm.xml" pour le mappage ORM.