Тестване на личен метод с помощта на mockito

Не можете да направите това с Mockito, но можете да използвате Powermock, за да разширите Mockito и да имитирате частни методи. Powermock поддържа Mockito. Ето един пример.

Не е възможно чрез mockito. От тяхното wiki

Защо Mockito не се подиграва с частни методи?

Първо, ние не сме догматични по отношение на подигравките с частни методи. Просто не ни интересуват частните методи, защото от гледна точка на тестването частни методи не съществуват. Ето няколко причини Mockito да не се подиграва на частните методи:

Изисква хакване на програми за зареждане на класове, което никога не е бронирано и променя API (трябва да използвате персонализиран тестов инструмент, да анотирате класа и т.н.).

Много е лесно да се заобиколи - просто променете видимостта на метода от частен на защитен от пакет (или защитен).

Това изисква от мен да отделям време за внедряването и поддържането му. И няма смисъл предвид точка #2 и факта, че вече е имплементирана в друг инструмент (powermock).

И накрая... Подигравката с частните методи е намек, че има нещо нередно с разбирането на OO. В OO искате обекти (или роли) да си сътрудничат, а не методи. Забравете за паскала и процедурния код. Мислете в обекти.

Ето малък пример как да го направите с powermock

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

За да тествате method1 използвайте код:

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

За да зададете частен обект obj използвайте това:

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

Докато Mockito не предоставя тази възможност, можете да постигнете същия резултат, като използвате Mockito + класа JUnit ReflectionUtils или Spring ReflectionTestUtils клас. Моля, вижте пример по-долу, взет от тук, обясняващ как за извикване на частен метод:

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

Пълни примери с ReflectionTestUtils и Mockito могат да бъдат намерени в книгата Mockito за пролетта

Мислете за това от гледна точка на поведение, а не от гледна точка на това какви методи има. Методът, наречен method, има определено поведение, ако b е вярно. Има различно поведение, ако b е невярно. Това означава, че трябва да напишете два различни теста за method; по един за всеки случай. Така че вместо да имате три теста, ориентирани към метода (един за method, един за method1, един за method2, имате два теста, ориентирани към поведението.

Свързано с това (предложих това в друга тема на SO наскоро и в резултат на това ме нарекоха дума от четири букви, така че не се колебайте да приемете това със зърно сол); Намирам за полезно да избирам имена на тестове, които отразяват поведението, което тествам, а не името на метода. Така че не наричайте тестовете си testMethod(), testMethod1(), testMethod2() и така нататък. Харесвам имена като calculatedPriceIsBasePricePlusTax() или taxIsExcludedWhenExcludeIsTrue(), които показват какво поведение тествам; след това в рамките на всеки тестов метод тествайте само посоченото поведение. Повечето такива поведения ще включват само едно извикване на публичен метод, но могат да включват много извиквания на частни методи.

Надявам се това да помогне.

1. Чрез използване на отражение частните методи могат да бъдат извикани от тестови класове. В такъв случай,

   // методът на тестване ще бъде като този ...

   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. Ако частният метод извиква друг частен метод, тогава трябва да шпионираме обекта и да заглушим друг метод. Тестовият клас ще бъде като ...

   // методът на тестване ще бъде като този ...

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

**Подходът е да се комбинира отражение и шпиониране на обекта. **method1 и **method2 са частни методи и method1 извиква метод2.

Не трябва да тествате частни методи. Трябва да се тестват само нечастни методи, тъй като те така или иначе трябва да извикват частните методи. Ако „искате“ да тествате частни методи, това може да означава, че трябва да преосмислите своя дизайн:

Използвам ли правилно инжектиране на зависимост? Възможно ли е да преместя частните методи в отделен клас и по-скоро да го тествам? Трябва ли тези методи да са лични? ... не могат ли да бъдат по подразбиране или по-скоро защитени?

В горния пример, двата метода, които се наричат ​​„случайно“, може действително да трябва да бъдат поставени в собствен клас, тествани и след това инжектирани в класа по-горе.

Успях да тествам частен метод вътре, използвайки mockito, използвайки отражение. Ето примера, опитах се да го нарека така, че да има смисъл

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

Наистина не разбирам нуждата ви да тествате частния метод. Основният проблем е, че вашият публичен метод има void като тип на връщане и следователно не можете да тествате своя публичен метод. Следователно вие сте принудени да тествате личния си метод. Правилно ли е предположението ми??

Няколко възможни решения (AFAIK):

1. Подигравайки се с личните си методи, но все пак няма да "действително" тествате методите си.

2. #P4#

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

   #P5#

3. Преработете малко кода си (Надявам се, че това не е наследен код). Моята основа за писане на метод е, че човек винаги трябва да връща нещо (int/булев). Върнатата стойност МОЖЕ или НЕ МОЖЕ да се използва от изпълнението, но СИГУРНО ще БЪДЕ използвана от теста

   код.

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

Всъщност има начин да тествате методи от частен член с Mockito. Да приемем, че имате клас като този:

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

Ако искате да тествате a.method ще извика метод от SomeOtherClass, можете да напишете нещо подобно по-долу.

@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(); ще заличи личния член с нещо, което можете да шпионирате.

Поставете теста си в същия пакет, но различна папка източник (src/main/java срещу src/test/java) и направете тези методи пакетни частни. Възможността за тестване на Imo е по-важна от поверителността.

В случаите, когато частният метод не е невалиден и върнатата стойност се използва като параметър към метода на външна зависимост, можете да се подиграете на зависимостта и да използвате ArgumentCaptor, за да уловите върнатата стойност. Например:

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