unit-testing - tutorial - pruebas unitarias android ejemplo

Prueba de unidad Java: Reemplazar un método privado bajo prueba

Question

¿Hay alguna forma de reemplazar la lógica dentro de un método privado cuando se ejecuta una prueba JUnit?

Un poco de historia: tenemos algunos métodos privados que interactúan con paquetes dentro de un contenedor OSGi. Esto no está disponible en la prueba unitaria, por lo tanto, los métodos fallarán.

Hemos analizado JMockIt, pero la funcionalidad de sustitución de método parece querer obligarlo a reemplazar todos los métodos de la clase que se llaman entre sí.

La implementación sería algo como esto:

public final doSomething() {
firstThing();
secondThing();
}
private firstThing() {
// normal code
}
private secondThing() {
// code which is unavailable in a unit test
}

Y la prueba unitaria especificaría la nueva implementación de secondThing ():

// replace secondThing() in impl with this secondThing()
private secondThing() {
// dummy code
}
// run tests

Answer 1

Está acoplando su implementación a la creación del objeto osgi (haciéndolo dentro de secondThing () o la clase misma). Si aprobó la implementación en su clase desde el exterior, podría usar un stub / mock al realizar la prueba.

Answer 2

Mi consejo: rediseña tu aplicación. Si desea cambiar el comportamiento de un método private :

• hacer que sea protected / public y anularlo en un objeto simulado
• mover la funcionalidad fuera del método a una clase auxiliar, que es inyectable (mediante inyección de dependencia). Luego simulad a ese ayudante e inyecta el simulacro en la clase bajo prueba, en lugar del heloper original.

Una solución puede ser alguna técnica de manipulación de código de bytes, pero no lo recomiendo.

Answer 3

También creo que la inyección de dependencia resolvería este problema. Si no quiere otro marco en su proyecto y este es el único lugar que crea problemas, puede definir una interfaz para secondThing y tener 2 implementaciones para eso, una para el código original y otra vacía para el unittest.

Answer 4

Ciertamente puedes resolver esta situación con JMockit. Una forma sería definir una clase de "maqueta", por ejemplo:

public class MyTest
{
@Test
public void testDoSomething()
{
new MockUp<ClassWhichDependsOnOtherBundles>()
{
@Mock
void secondThing()
{
// do anything here
}
};
new ClassWhichDependsOnOtherBundles().doSomething();
}
}

Solo el método secondThing() en la clase simulada será reemplazado por JMockit. La API de JMockit Expectations también podría usarse, con burlas parciales.

Answer 5

hay un buen patrón de stub

ProductionClass.java:

public class ProductionClass {
...
//default visibility to make it available for stubbing
void firstThing(){...}
...
}

BlaTest.java (el mismo paquete que la clase de producción):

public class BlaTest {
@Test
void test_xx(){
//use stubbed impl
ProductionClass sut = new ProductionClassStubbed();
sut.doSomething();
}
}
class ProductionClassStubbed extends ProductionClass{
@Override
void firstThing(){
//stub out fill in what you want (like dummy behaviour)
}
}

Una cosa diferente Vi un modificador final en tu código de muestra. Tenga cuidado con el uso del modificador final . Son malos para la capacidad de prueba. Solo use si realmente es realmente necesario.