Тестирование частного метода с использованием mockito

Вы не можете сделать это с Mockito, но вы можете использовать Powermock для расширения Mockito и имитации частных методов. Powermock поддерживает Mockito. Вот пример.

Невозможно через mockito. Из их вики

Почему Mockito не издевается над частными методами?

Во-первых, мы не догадываемся о насмешках над частными методами. Нас просто не волнуют частные методы, потому что с точки зрения тестирования частных методов не существует. Вот пара причин, по которым Mockito не издевается над частными методами:

Это требует взлома загрузчиков классов, который никогда не бывает пуленепробиваемым, и меняет api (вы должны использовать собственный тестовый бегун, аннотировать класс и т. Д.).

Обойти это очень просто - просто измените видимость метода с частного на защищенный пакетом (или защищенный).

Это требует, чтобы я тратил время на его внедрение и поддержку. И это не имеет смысла, учитывая пункт №2 и тот факт, что он уже реализован в другом инструменте (powermock).

Наконец ... Мокинг приватных методов - это намек на то, что что-то не так с объектно-ориентированным пониманием. В объектно-ориентированном стиле вы хотите, чтобы взаимодействовали объекты (или роли), а не методы. Забудьте о паскале и процедурном коде. Думайте объектами.

Вот небольшой пример того, как это сделать с помощью powermock.

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

Чтобы проверить метод1, используйте код:

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 for Spring

Подумайте об этом с точки зрения поведения, а не с точки зрения существующих методов. Метод, называемый 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 вызывает method2.

Вы не должны тестировать частные методы. Необходимо тестировать только не приватные методы, так как они в любом случае должны вызывать частные методы. Если вы «хотите» протестировать частные методы, это может означать, что вам нужно переосмыслить свой дизайн:

Я использую правильную инъекцию зависимостей? Возможно, мне нужно переместить частные методы в отдельный класс и проверить это? Эти методы должны быть частными? ... не могут ли они быть по умолчанию или защищены?

В приведенном выше примере два метода, которые называются «случайным образом», может потребоваться поместить в отдельный класс, протестировать и затем внедрить в класс выше.

Я смог протестировать частный метод внутри, используя 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 / a boolean). Возвращаемое значение МОЖЕТ или НЕ МОЖЕТ использоваться реализацией, но ОБЯЗАТЕЛЬНО БУДЕТ использоваться тестом.

   код.

   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 vs. 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");