Тестовый пример Junit для частного метода

Прежде всего пара вещей:

1. Почему loading_status статичен? В основном 2 экземпляра этого класса будут использовать одну и ту же переменную loading_status. loading_status либо не должен быть статическим, либо checkLoadingStatus также должен быть статическим.
2. loading_status ужасно назван. Если вы хотите, чтобы он оставался статичным, вы должны назвать его LOADING_STATUS. Если он не будет статичным, назовем его loadingStatus. Это соглашение Java.
3. Вы должны создать правильный тип перечисления для loading_status, а не целое число.
4. while (loading_status == IN_PROGRESS); это просто плохая практика. По крайней мере, что вы можете сделать, это: while(loading_status == IN_PROGRESS) { Thread.sleep(100); }; Однако тайм-аут является лучшей практикой. Что-то вроде:

long timeoutMillis = 5000L; // Should come from a configuration or something
long endTimeMillis = System.currentTimeMillis() + timeoutMillis;
while (loadingStatus == IN_PROGRESS) {
    long remainingMillis = end - System.currentTimeMillis();
    if (remaining <= 0) {
        // Timeout while loading
        loadingStatus = LOADING_ERROR;
        break;
    }
    Thread.sleep(50);
}
// ...

И, наконец, я думаю, что что-то изменит статус загрузки на завершенный или что-то в этом роде. Я думаю, вы также используете синхронизированный. Если загрузка происходит в двух разных потоках, вы окажетесь в тупике. Если checkLoadingStatus сначала войдет в синхронизированный блок, поэтому, когда загрузка будет завершена, поток загрузки никогда не сможет войти в синхронизированный блок, потому что checkLoadingStatus удерживает блокировку.

И последнее, но не менее важное, чтобы ответить на ваш вопрос, если вы хотите сохранить свой метод закрытым, вы можете вызвать его через отражение, но это снова плохая практика. Как правило, вам следует избегать модульного тестирования частных методов и модульного тестирования тех методов, которые его вызывают. Однако, если вам определенно нужно выполнить модульное тестирование определенного метода, сделайте его закрытым для пакета, а не частным, а затем вы можете создать модульный тест в том же пакете, где находится класс, содержащий ваш метод. И вы можете добавить комментарий к методу, говоря, что он виден только для модульного тестирования. Пример вашей структуры кода в этом случае:

src
+-- main
+-- +-- com/app/MyClass.java
+-- test
    +-- com/app/MyClassTest.java // this test class will able to access package-private methods in MyClass

Обычно, когда вы не можете протестировать свой код, вам следует подумать о его переписывании, чтобы его можно было протестировать. Частные методы нельзя вызывать обычным способом, вне вашего класса, даже в тесте JUnit.

Есть несколько вещей, которые вы можете сделать, чтобы сделать его пригодным для тестирования:

1. Перепишите свой код, чтобы разделить метод на более мелкие. Всегда нужно делать там, где это уместно.

2. Вы можете сделать пакет метода закрытым (удалить модификатор private), чтобы ваш тестовый класс, который должен находиться в том же пакете, мог получить к нему доступ.

3. Вы можете сделать метод защищенным, чтобы вы могли наследовать свой класс в своем тесте и косвенно вызывать этот метод над вашим унаследованным классом.

4. Вы можете вызвать метод, который вызывает метод, который вы хотите протестировать, и сделать соответствующие утверждения.

Если вы склонны изменять видимость метода для пакета private или protected, вы можете аннотировать свой метод как @VisibleForTesting, чтобы такие инструменты, как Sonar и другие члены команды, знали, почему он не является закрытым.

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

Ваш частный метод работает в соответствии со значением внутренней частной переменной loading_status, поэтому в ваших тестах вы должны иметь возможность просто изменить эту переменную. Для этого вы можете сделать следующее:

package com.test

import com.test.SchemaMaintenance;
import org.junit.Test;
import org.mockito.internal.util.reflection.Whitebox;

public class SchemaMaintenanceTest {

    @Test
    public void TestSchema() throws Exception {
        SchemaMaintenance schema = new SchemaMaintenance();
        Whitebox.setInternalState(schema,"loading_status",2);
        schema.startSchemaMaintenance();
    }

}

Предположим, вы должны включить в свой проект зависимость mockito:

напр. Мейвен

<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-api-mockito</artifactId>
  <version>1.6.4</version>
</dependency>

Вот подход, который сработал для меня.

1. Make a public "tester" inner class in your class.
   • If you are testing an inner class the "tester" still needs to be on the outer class.
2. Тестер — это делегат для частных методов, которые вы хотите протестировать.
3. Добавьте в свой класс метод для получения экземпляра тестера.
4. В вашем тестовом методе получите экземпляр тестера и
5. Вызовите свой частный метод через соответствующий метод экземпляра тестера.

Будут разные варианты в зависимости от требуемого доступа к методам и внутренним классам и т.д.

В этом примере не может быть статического тестера, потому что нам нужно было протестировать методы в нестатическом внутреннем классе.

//  Outer owner class
//
public class OwnerClass Class {
    
    private class InnerClass {
            : 
            
        //  method I'm testing
        //
        private void doSomething)( String name ){
            ...
        }
    }
    
        :
    
    //  Tester class
    //
    public class InnerClassTester {
        
        private final InnerClass        innerClass    = new InnerClass();
            :
            
        //  test invocatiion
        //
        private void doSomething)( String name ){
            
            innerClass.doSomething)( name )
        }
    }

    //  Get an instance of the tester
    //    
    public InnerClassTester getInnerClassTester() {
        return new InnerClassTester();
    }

Внутри вашего модульного теста...

@Test
public void doSomethingTest() throws Exception {
    
    OwnerClass ownerClass = new OwnerClass();
    innerClassTester      = ownerClass.InnerClassTester();
            :
            
    //  Test the private method
    //
    innerClassTester.doSomething( "123456" );
}

Работает с отладчиком. Вы должны быть гибкими, определяя тестер и тестер-геттер в зависимости от вашего доступа. Тестер наверное тоже может быть protected, я так не пробовал. Всего наилучшего.