Reputation: 61
I would do a mock for a call inside a function who receive a list and return a String. I tried follow several webs but i can not understan how adapt the code for my case. I have this code to mock:
public class Procesa {
public String preparaComando (List <String> comando){
Prepara prepara = new Prepara();
List <String> comandoCodificado = new ArrayList<String>();
comandoCodificado = prepara.preparaTexto(comando);
String textoRetorno = "";
for (String cadena : comando)
textoRetorno+= cadena + " ";
return textoRetorno;
}
....
}
And I tried do this test:
@RunWith(MockitoJUnitRunner.class)
public class ProcesaTest {
@Mock
Procesa procesa = mock(Procesa.class);
@Mock
Prepara preparaCom = mock(Prepara.class);
....
@Test
public void TestPreparaComando() {
List lista = new ArrayList<>();
lista.add("encenderluzcocina");
verify(procesa).preparaComando(anyList()).contains("encender");
assertEquals("encenderluzcocina", procesa.preparaComando(anyList()));
}
}
How can I test this function?
Upvotes: 1
Views: 710
Reputation: 16390
Just to complement the other answer, we could also write a so-called white box test (also known as an "isolated unit test") where the Prepara
dependency is mocked.
For example, the following test could be written (using the JMockit mocking library here, others could be used as well):
public class ProcesaTest
{
@Tested Procesa procesa;
@Mocked Prepara preparaCom;
@Test
public void preparaComando() {
final List<String> comando = asList("a", "b", "c");
new Expectations() {{
preparaCom.preparaTexto(comando); returns("encender", "luzcocina");
}};
String result = procesa.preparaComando(comando);
assertEquals("encender luzcocina", result);
}
}
This said, though, a black box test is almost always better than a white box test.
Upvotes: 1
Reputation: 140553
You should not use any mocking to test such code. Your method receives a list of strings; and it returns a string. That should be all that matters.
In other words: your method has a certain contract: given input X, it should deliver output Y. How that method comes from X to Y - that goes under implementation details. And you do not test implementation details.
So, in short, the answer is: you step back, and figure the complete set of meaningful input values { X1, X2, ..., Xn }. Then you determine which output values { Y1, Y2, ... Yn } correspond to each input. Now you write n tests; one for each pair Xi, Yi.
[hint: it might also be a valid "Yi" to expect a certain exception to be thrown; instead of a value being returned ]
Long story shorts: if your method has such a nice input/output setup; then you should only test it using asserts. If your method works by changing other things within your class under test; then consider adding getters that allow you to inspect that state.
And if mocking is required, then you should use dependency injection in order to provide a "mocked" thingy into your class under test.
Finally: if you are interested in learning how to write testable code, watch these videos!
Upvotes: 1