Testowanie metody prywatnej przy użyciu mockito

klasa publiczna A {

    public void method (boolean b) {
          jeśli (b == prawda)
               metoda1 ();
          jeszcze
               metoda2 ();
    }

    private void method1 () {}
    private void method2 () {}
}

public class TestA {

    @Test
    public void testMethod () {
      A a = mock (klasa A.);
      a. metoda (prawda);
      // jak testować jak verify (a) .method1 ();
    }
}

Jak testować metodę prywatną jest wywoływana czy nie, a jak testować metodę prywatną używając mockito ???

Nie możesz tego zrobić z Mockito, ale możesz użyć Powermock, aby rozszerzyć Mockito i udawać metody prywatne. Powermock obsługuje Mockito. Oto przykład.

Niemożliwe przez mockito. Z ich wiki

Dlaczego Mockito nie kpi z prywatnych metod?

Po pierwsze, nie jesteśmy dogmatyczni, jeśli chodzi o kpienie z prywatnych metod. Po prostu nie dbamy o metody prywatne, ponieważ z punktu widzenia testowania metody prywatne nie istnieją. Oto kilka powodów, dla których Mockito nie kpi z prywatnych metod:

Wymaga hakowania programów ładujących klasy, które nigdy nie są kuloodporne i zmienia interfejs API (musisz użyć niestandardowego modułu uruchamiającego testy, dodać adnotację do klasy itp.).

Jest to bardzo łatwe do obejścia - wystarczy zmienić widoczność metody z prywatnej na chronioną pakietem (lub chronioną).

Wymaga to poświęcenia czasu na jego wdrożenie i utrzymanie. I nie ma to sensu biorąc pod uwagę punkt # 2 i fakt, że jest już zaimplementowany w innym narzędziu (powermock).

Wreszcie ... Kpiny z prywatnych metod to wskazówka, że ​​coś jest nie tak ze zrozumieniem OO. W OO chcesz, aby współpracowały ze sobą obiekty (lub role), a nie metody. Zapomnij o pascalu i kodzie proceduralnym. Myśl w przedmiotach.

Oto mały przykład, jak to zrobić z powermockiem

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

Aby przetestować metodę 1 użyj kodu:

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

Aby ustawić prywatny obiekt OBJ użyj tego:

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

Pomyśl o tym w kategoriach zachowania, a nie w kategoriach dostępnych metod. Wywołana metoda methodma określone zachowanie, jeśli bjest prawdziwe. Zachowuje się inaczej, jeśli bjest fałszywe. Oznacza to, że powinieneś napisać dwa różne testy method; po jednym w każdym przypadku. Więc zamiast trzech testów zorientowanych na metodę (jeden za method, jeden za method1, jeden za method2, masz dwa testy zorientowane na zachowanie).

Związane z tym (zasugerowałem to niedawno w innym wątku SO, iw rezultacie zostałem nazwany czteroliterowym słowem, więc możesz to wziąć z przymrużeniem oka); Uważam, że pomocne jest wybranie nazw testów, które odzwierciedlają zachowanie, które testuję, zamiast nazwy metody. Więc nie nazywaj swoje testy testMethod(), testMethod1(), testMethod2()i tak dalej. Lubię takie imionacalculatedPriceIsBasePricePlusTax() lub, taxIsExcludedWhenExcludeIsTrue()które wskazują, jakie zachowanie testuję; następnie w ramach każdej metody testowej testuj tylko wskazane zachowanie. Większość takich zachowań obejmuje tylko jedno wywołanie metody publicznej, ale może obejmować wiele wywołań metod prywatnych.

Mam nadzieję że to pomoże.

Chociaż Mockito nie zapewnia takiej możliwości, ten sam wynik można osiągnąć za pomocą Mockito + klasy JUnit ReflectionUtils lub klasy Spring ReflectionTestUtils . Zobacz poniższy przykład zaczerpnięty stąd, wyjaśniający, jak wywołać metodę prywatną:

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

Pełne przykłady z ReflectionTestUtils i Mockito można znaleźć w książce Mockito na wiosnę

Nie powinieneś testować prywatnych metod. Należy przetestować tylko metody nieprywatne, ponieważ i tak powinny one wywoływać metody prywatne. Jeśli „chcesz” przetestować metody prywatne, może to oznaczać, że musisz przemyśleć swój projekt:

Czy używam odpowiedniego wstrzyknięcia zależności? Czy muszę przenieść metody prywatne do osobnej klasy i raczej to przetestować? Czy te metody muszą być prywatne? ... czy nie mogą być domyślne czy raczej chronione?

W powyższym przypadku dwie metody, które są nazywane „losowo”, mogą w rzeczywistości wymagać umieszczenia w osobnej klasie, przetestowania, a następnie wstrzyknięcia do klasy powyżej.

1. Korzystając z odbicia, można wywołać metody prywatne z klas testowych. W tym przypadku,

   // metoda testowa będzie taka ...

   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. Jeśli metoda prywatna wywoła jakąkolwiek inną metodę prywatną, musimy szpiegować obiekt i zablokować inną metodę. Klasa testowa będzie wyglądać następująco ...

   // metoda testowa będzie taka ...

   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);
   
       }
   }

** Podejście polega na połączeniu refleksji i podglądania obiektu. ** metoda1 i ** metoda2 to metody prywatne, a metoda1 wywołuje metodę2.

Udało mi się przetestować prywatną metodę wewnątrz za pomocą mockito z wykorzystaniem refleksji. Oto przykład, próbowałem nazwać go tak, aby miał sens

//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));

Naprawdę nie rozumiem twojej potrzeby testowania metody prywatnej. Główny problem polega na tym, że twoja metoda publiczna ma void jako typ zwracany i dlatego nie możesz przetestować swojej metody publicznej. Dlatego jesteś zmuszony przetestować swoją prywatną metodę. Czy moje przypuszczenie jest prawidłowe?

Kilka możliwych rozwiązań (AFAIK):

1. Kpiąc ze swoich prywatnych metod, ale nadal nie będziesz „faktycznie” testować swoich metod.

2. Sprawdź stan obiektu używanego w metodzie. MOSTLY metody albo wykonują pewne przetwarzanie wartości wejściowych i zwracają dane wyjściowe, albo zmieniają stan obiektów. Można również zastosować testowanie obiektów pod kątem pożądanego stanu.

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

   [Tutaj możesz przetestować metodę prywatną, sprawdzając zmianę stanu classObj z null na not null.]

3. Zmień trochę kod (mam nadzieję, że nie jest to starszy kod). Moją podstawą pisania metody jest to, że zawsze należy coś zwracać (int / a boolean). Zwrócona wartość MOŻE lub NIE MOŻE zostać użyta przez implementację, ale PEWNIE BĘDZIE wykorzystana przez test

   kod.

   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() {}
   
   }

W rzeczywistości istnieje sposób na przetestowanie metod od prywatnego członka za pomocą Mockito. Powiedzmy, że masz taką klasę:

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() {}
}

Jeśli chcesz, aby test a.methodwywołał metodę z SomeOtherClass, możesz napisać coś takiego jak poniżej.

@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(); zablokuje prywatnego członka czymś, co możesz szpiegować.

Umieść test w tym samym pakiecie, ale w innym folderze źródłowym (src / main / java vs. src / test / java) i ustaw te metody jako pakiet-prywatny. Testowalność Imo jest ważniejsza niż prywatność.

W przypadkach, gdy metoda prywatna nie jest void, a wartość zwracana jest używana jako parametr metody zależności zewnętrznej, można mockować zależność i użyć znaku ArgumentCaptordo przechwycenia wartości zwracanej. Na przykład:

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