tipos - paso de parametros en java ejemplo

¿Cómo se burla el método privado que modifica las variables privadas?

Question

¿Cómo se burla el método privado que modifica las variables privadas?

class SomeClass{
private int one;
private int second;
public SomeClass(){}
public int calculateSomething(){
complexInitialization();
return this.one + this.second;
}
private void complexInitialization(){
one = ...
second = ...
}
}

Answer 1

A condición de que otras respuestas señalen que esos casos de prueba son frágiles y que los casos de prueba no deben basarse en la implementación y deben depender del comportamiento si aún desea burlarse de ellos, a continuación se incluyen algunas maneras:

PrivateMethodDemo tested = createPartialMock(PrivateMethodDemo.class,
"sayIt", String.class);
String expected = "Hello altered World";
expectPrivate(tested, "sayIt", "name").andReturn(expected);
replay(tested);
String actual = tested.say("name");
verify(tested);
assertEquals("Expected and actual did not match", expected, actual);

Así es como lo harías con PowerMock.

expectPrivate () de PowerMock hace esto.

Casos de prueba de PowerMock que prueban el método privado burlándose

ACTUALIZACIÓN: burla parcial con PowerMock hay algunas renuncias y capturas

class CustomerService {
public void add(Customer customer) {
if (someCondition) {
subscribeToNewsletter(customer);
}
}
void subscribeToNewsletter(Customer customer) {
// ...subscribing stuff
}
}

Luego, crea una simulación PARCIAL de CustomerService, que proporciona una lista de los métodos que desea simular.

CustomerService customerService = PowerMock.createPartialMock(CustomerService.class, "subscribeToNewsletter");
customerService.subscribeToNewsletter(anyObject(Customer.class));
replayAll();
customerService.add(createMock(Customer.class));

Entonces add() dentro del simulacro CustomerService es lo REAL que desea probar y para el método subscribeToNewsletter() ahora puede escribir una expectativa como de costumbre.

Answer 2

Power Mock podría ayudarte aquí. Pero, en general, protegería el método y anularía el método previamente privado de hacer lo que quisiera.

Answer 3

No , porque su prueba dependerá de los detalles de implementación de la clase que está probando y, por lo tanto, será frágil. Podría refactorizar su código de modo que la clase que está probando actualmente dependa de otro objeto para hacer este cálculo. Entonces puedes burlarte de esta dependencia de la clase bajo prueba. O deja los detalles de implementación a la clase en sí y prueba suficientemente su comportamiento observable.

El problema que podría sufrir es que no está exactamente separando comandos y consultas a su clase. calculateSomething parece más a una consulta, pero complexInitialization es más un comando.