¿Cómo puedo simular fácilmente un método estático en Java (jUnit4)

Question

¿Cómo puedo simular fácilmente un método estático en Java?

estoy utilizando Spring 2.5 y JUnit 4,4

@Service 
public class SomeServiceImpl implements SomeService { 

    public Object doSomething() { 
     Logger.getLogger(this.class); //a static method invoked. 
     // ... 
    } 
} 

no controlo el método estático que mi servicio necesita invocar así que no puedo refactor a ser más unidad comprobable. He usado el Log4J Logger como ejemplo, pero el método estático real es similar. No es una opción cambiar el método estático.

Hacer trabajo Grails, estoy acostumbrado a usar algo como:

def mockedControl = mockFor(Logger) 
mockControl.demand.static.getLogger{Class clazz-> … } 
… 
mockControl.verify() 

¿Cómo puedo hacer algo similar en Java?

Answer 1

Básicamente, no hay una manera fácil de hacer esto en Java + Spring 2.5 & JUnit 4.4 en este momento.

Aunque es posible refactorizar y abstraer la llamada estática, Refactorizar el código no es la solución que estaba buscando.

JMockit parecía que funcionaría, pero es incompatible con Spring 2.5 y JUnit 4.4.

Answer 2

¿Quiere decir que no puede controlar el código de llamada? Porque si controla las llamadas a el método estático pero no la implementación en sí, puede hacer que sea fácilmente comprobable. Cree una interfaz de dependencia con un único método con la misma firma que el método estático. Su implementación de producción simplemente llamará al método estático, pero cualquier cosa que actualmente llame al método estático llamará a través de la interfaz.

Puede simular esa interfaz de la forma habitual.

Answer 3

public interface LoggerWrapper { 
    public Logger getLogger(Class<?> c); 
    } 
public class RealLoggerWrapper implements LoggerWrapper { 
    public Logger getLogger(Class<?> c) {return Logger.getLogger(c);} 
    } 
public class MockLoggerWrapper implements LoggerWrapper { 
    public Logger getLogger(Class<?> c) {return somethingElse;} 
    } 

Answer 4

Esa es una de las razones por las que los métodos estáticos son malos.

Hemos rediseñado la mayoría de nuestras fábricas para tener también instaladores para poder establecer falsos objetos en ellas. De hecho, se nos ocurrió algo parecido a la inyección de dependencia, donde un único método funcionaba como una fábrica para todos nuestros singletons.

En su caso, agregar un método Logger.setLogger() (y almacenar ese valor) podría funcionar. Si es necesario, puede ampliar la clase de registrador y seguir el método getLogger con el suyo.

Answer 5

El marco JMockit promete permitir la burla de métodos estáticos.

https://jmockit.dev.java.net/

De hecho, hace algunas afirmaciones bastante llamativos, incluyendo que los métodos estáticos son una opción de diseño perfectamente válido y su uso no deben restringirse a causa de la insuficiencia de infraestructuras de prueba.

Independientemente de si estas afirmaciones son justificables, el marco de JMockit en sí es bastante interesante, aunque todavía tengo que probarlo.

Answer 6

Puede utilizar AspectJ para interceptar la llamada al método estático y hacer algo útil para su prueba.

Answer 7

Como otra respuesta mencionada anteriormente, JMockit puede simular métodos estáticos (y cualquier otra cosa, también).

Incluso tiene soporte directo para estructuras de registro. Por ejemplo, puede escribir:

@UsingMocksAndStubs(Log4jMocks.class) 
public class SomeServiceTest 
{ 
    // All test methods in this class will have any calls 
    // to the Log4J API automatically stubbed out. 
} 

El soporte para JUnit 4.4 se ha caído, sin embargo. JUnit 3.8, JUnit 4.5+ y TestNG 5.8+ son compatibles.

Answer 8

PowerMock tiene esta capacidad. También puede simular instancias de objetos dentro de la clase bajo prueba. Si su método probado llama al nuevo Foo(), puede crear un objeto simulado para ese Foo y reemplazarlo en el método que está probando.

Cosas como la supresión de constructores e inicializadores estáticos también son posibles. Todas estas cosas se consideran código no comprobable y, por lo tanto, no se recomienda hacer, pero si tiene código heredado, cambiarlo no siempre es una opción. Si se encuentra en esa posición, PowerMock puede ayudarlo.