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

public class A {

    public void method (boolean b) {
          если (b == истина)
               method1 ();
          еще
               method2 ();
    }

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

public class TestA {

    @Тест
    public void testMethod () {
      A a = mock (класс A.)
      a.method (истина);
      // как тестировать как verify (a) .method1 ();
    }
}

Как проверить вызывается частный метод или нет, и как протестировать частный метод с помощью 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);

Подумайте об этом с точки зрения поведения, а не с точки зрения имеющихся методов. Вызываемый метод methodимеет особое поведение, если bистинно. Если bэто false, он ведет себя иначе . Это означает, что вам следует написать два разных теста для method; по одному на каждый случай. Таким образом, вместо трех тестов, ориентированных на метод (один для method, один для method1, один для method2, у вас есть два теста, ориентированных на поведение.

В связи с этим (я недавно предложил это в другом треде SO, и в результате меня назвали словом из четырех букв, так что не стесняйтесь относиться к этому с недоверием); Я считаю полезным выбирать имена тестов, которые отражают поведение, которое я тестирую, а не имя метода. Так что не называют тесты testMethod(), testMethod1(), testMethod2()и так далее. Мне нравятся такие имена, как calculatedPriceIsBasePricePlusTax()или taxIsExcludedWhenExcludeIsTrue()которые указывают, какое поведение я тестирую; затем в каждом методе тестирования проверьте только указанное поведение. В большинстве случаев такое поведение будет включать только один вызов общедоступного метода, но может включать много вызовов частных методов.

Надеюсь это поможет.

Хотя Mockito не предоставляет такой возможности, вы можете добиться того же результата, используя Mockito + класс JUnit ReflectionUtils или класс Spring ReflectionTestUtils . См. Пример ниже, взятый отсюда, объясняющий, как вызвать частный метод:

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

Полные примеры с ReflectionTestUtils и Mockito можно найти в книге Mockito for Spring.

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

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

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

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. Проверьте состояние объекта, используемого в методе. В большинстве своем методы либо выполняют некоторую обработку входных значений и возвращают выходные данные, либо изменяют состояние объектов. Также можно использовать тестирование объектов на предмет желаемого состояния.

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

   [Здесь вы можете протестировать частный метод, проверив изменение состояния classObj с нуля на ненулевое.]

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