Probando el método privado usando mockito

clase pública A {

    método de vacío público (booleano b) {
          si (b == verdadero)
               Método 1();
          más
               método2 ();
    }

    método vacío privado1 () {}
    método vacío privado2 () {}
}

clase pública TestA {

    @Prueba
    testMethod de vacío público () {
      A a = simulacro (A.clase);
      un método (verdadero);
      // cómo probar como verify (a) .method1 ();
    }
}

¿Cómo probar el método privado se llama o no, y cómo probar el método privado usando mockito?

No puede hacer eso con Mockito, pero puede usar Powermock para extender Mockito y simular métodos privados. Powermock es compatible con Mockito. He aquí un ejemplo.

No es posible a través de mockito. De su wiki

¿Por qué Mockito no se burla de los métodos privados?

En primer lugar, no somos dogmáticos sobre burlarnos de los métodos privados. Simplemente no nos importan los métodos privados porque desde el punto de vista de probar los métodos privados no existen. Aquí hay un par de razones por las que Mockito no se burla de los métodos privados:

Requiere pirateo de cargadores de clases que nunca es a prueba de balas y cambia la API (debe usar un corredor de prueba personalizado, anotar la clase, etc.).

Es muy fácil solucionarlo: simplemente cambie la visibilidad del método de privado a protegido por paquete (o protegido).

Requiere que dedique tiempo a implementarlo y mantenerlo. Y no tiene sentido dado el punto # 2 y un hecho que ya está implementado en otra herramienta (powermock).

Finalmente ... Burlarse de los métodos privados es una pista de que hay algo mal en la comprensión de OO. En OO quieres que los objetos (o roles) colaboren, no métodos. Olvídese de pascal y el código de procedimiento. Piense en objetos.

Aquí hay un pequeño ejemplo de cómo hacerlo con powermock.

public class Hello {
    private Hello obj;
    private Integer method1(Long id) {
        return id + 10;
    }
} 

Para probar el método 1 use el código:

Hello testObj = new Hello();
Integer result = Whitebox.invokeMethod(testObj, "method1", new Long(10L));

Para establecer el objeto privado obj use esto:

Hello testObj = new Hello();
Hello newObject = new Hello();
Whitebox.setInternalState(testObj, "obj", newObject);

Piense en esto en términos de comportamiento, no en términos de los métodos que existen. El método llamado methodtiene un comportamiento particular si bes verdadero. Tiene un comportamiento diferente si bes falso. Esto significa que debe escribir dos pruebas diferentes para method; uno para cada caso. Entonces, en lugar de tener tres pruebas orientadas a métodos (una para method, una para method1, una para method2, tiene dos pruebas orientadas al comportamiento.

Relacionado con esto (sugerí esto en otro hilo de SO recientemente, y como resultado me llamaron una palabra de cuatro letras, así que siéntase libre de tomar esto con un grano de sal); Encuentro útil elegir nombres de prueba que reflejen el comportamiento que estoy probando, en lugar del nombre del método. Así que no llame a sus pruebas testMethod(), testMethod1(), testMethod2()y así sucesivamente. Me gustan los nombres como calculatedPriceIsBasePricePlusTax()o taxIsExcludedWhenExcludeIsTrue()que indiquen qué comportamiento estoy probando; luego, dentro de cada método de prueba, pruebe solo el comportamiento indicado. La mayoría de estos comportamientos involucrarán solo una llamada a un método público, pero pueden involucrar muchas llamadas a métodos privados.

Espero que esto ayude.

Si bien Mockito no proporciona esa capacidad, puede lograr el mismo resultado usando Mockito + la clase JUnit ReflectionUtils o la clase Spring ReflectionTestUtils . Vea un ejemplo a continuación tomado de aquí que explica cómo invocar un método privado:

ReflectionTestUtils.invokeMethod(student, "saveOrUpdate", "From Unit test");

Se pueden encontrar ejemplos completos con ReflectionTestUtils y Mockito en el libro Mockito for Spring

Se supone que no debes probar métodos privados. Solo se deben probar los métodos no privados, ya que de todos modos deberían llamar a los métodos privados. Si "desea" probar métodos privados, puede indicar que necesita repensar su diseño:

¿Estoy usando la inyección de dependencia adecuada? ¿Es posible que deba mover los métodos privados a una clase separada y probar eso? ¿Deben estos métodos ser privados? ... ¿no pueden ser predeterminados o protegidos?

En el caso anterior, es posible que los dos métodos que se denominan "aleatoriamente" deban colocarse en una clase propia, probarse y luego inyectarse en la clase anterior.

Pude probar un método privado en el interior usando mockito usando la reflexión. Aquí está el ejemplo, intenté nombrarlo de tal manera que tenga sentido

//Service containing the mock method is injected with mockObjects

@InjectMocks
private ServiceContainingPrivateMethod serviceContainingPrivateMethod;

//Using reflection to change accessibility of the private method

Class<?>[] params = new Class<?>[]{PrivateMethodParameterOne.class, PrivateMethodParameterTwo.class};
    Method m = serviceContainingPrivateMethod .getClass().getDeclaredMethod("privateMethod", params);
    //making private method accessible
    m.setAccessible(true); 
    assertNotNull(m.invoke(serviceContainingPrivateMethod, privateMethodParameterOne, privateMethodParameterTwo).equals(null));

1. Al usar la reflexión, se pueden llamar a métodos privados desde clases de prueba. En este caso,

   // el método de prueba será así ...

   public class TestA {
   
     @Test
       public void testMethod() {
   
       A a= new A();
       Method privateMethod = A.class.getDeclaredMethod("method1", null);
       privateMethod.setAccessible(true);
       // invoke the private method for test
       privateMethod.invoke(A, null);
   
       }
   }

2. Si el método privado llama a cualquier otro método privado, entonces debemos espiar el objeto y eliminar el otro método. La clase de prueba será como ...

   // el método de prueba será así ...

   public class TestA {
   
     @Test
       public void testMethod() {
   
       A a= new A();
       A spyA = spy(a);
       Method privateMethod = A.class.getDeclaredMethod("method1", null);
       privateMethod.setAccessible(true);
       doReturn("Test").when(spyA, "method2"); // if private method2 is returning string data
       // invoke the private method for test
       privateMethod.invoke(spyA , null);
   
       }
   }

** El enfoque consiste en combinar la reflexión y el espionaje del objeto. ** método1 y ** método2 son métodos privados y el método1 llama al método2.

Realmente no entiendo tu necesidad de probar el método privado. La raíz del problema es que su método público ha sido nulo como tipo de retorno y, por lo tanto, no puede probar su método público. Por lo tanto, se ve obligado a probar su método privado. ¿Mi suposición es correcta?

Algunas posibles soluciones (AFAIK):

1. Burlarse de sus métodos privados, pero aún así no estará probando "realmente" sus métodos.

2. Verifique el estado del objeto utilizado en el método. LA MAYORÍA de los métodos procesan los valores de entrada y devuelven una salida, o cambian el estado de los objetos. También puede emplearse la prueba de los objetos para el estado deseado.

   public class A{
   
   SomeClass classObj = null;
   
   public void publicMethod(){
      privateMethod();
   }
   
   private void privateMethod(){
        classObj = new SomeClass();
   }
   
   }

   [Aquí puede probar el método privado, verificando el cambio de estado de classObj de nulo a no nulo].

3. Refactorice un poco su código (espero que no sea un código heredado). Mi fundamento para escribir un método es que siempre se debe devolver algo (un int / a booleano). El valor devuelto PUEDE o NO PUEDE ser utilizado por la implementación, pero SEGURO SERÁ utilizado por la prueba

   código.

   public class A
   { 
       public int method(boolean b)
       {
             int nReturn = 0;
             if (b == true)
                  nReturn = method1();
             else
                  nReturn = method2();
       }
   
       private int method1() {}
   
       private int method2() {}
   
   }

En realidad, hay una forma de probar métodos de un miembro privado con Mockito. Digamos que tienes una clase como esta:

public class A {
    private SomeOtherClass someOtherClass;
    A() {
        someOtherClass = new SomeOtherClass();
    }
    public void method(boolean b){
        if (b == true)
            someOtherClass.method1();
        else
            someOtherClass.method2();
    }

}

public class SomeOtherClass {
    public void method1() {}
    public void method2() {}
}

Si desea probar a.methodse invocará un método desde SomeOtherClass, puede escribir algo como a continuación.

@Test
public void testPrivateMemberMethodCalled() {
    A a = new A();
    SomeOtherClass someOtherClass = Mockito.spy(new SomeOtherClass());
    ReflectionTestUtils.setField( a, "someOtherClass", someOtherClass);
    a.method( true );

    Mockito.verify( someOtherClass, Mockito.times( 1 ) ).method1();
}

ReflectionTestUtils.setField(); tropezará al miembro privado con algo que pueda espiar.

Coloque su prueba en el mismo paquete, pero en una carpeta de origen diferente (src / main / java vs src / test / java) y haga que esos métodos sean privados del paquete. La comprobabilidad de la imitación es más importante que la privacidad.

En los casos en que el método privado no es nulo y el valor de retorno se usa como parámetro para el método de una dependencia externa, puede simular la dependencia y usar un ArgumentCaptorpara capturar el valor de retorno. Por ejemplo:

ArgumentCaptor<ByteArrayOutputStream> csvOutputCaptor = ArgumentCaptor.forClass(ByteArrayOutputStream.class);
//Do your thing..
verify(this.awsService).uploadFile(csvOutputCaptor.capture());
....
assertEquals(csvOutputCaptor.getValue().toString(), "blabla");