Использовать тест Reflection to Write для приватных методов

Question

У меня есть класс, NetworkManager.У меня есть много private методов, которые мне действительно нужны, чтобы написать для них test.

Сначала я не нашел никакого решения для написания test для моих частных методов.В любом случае, я нахожу способ получить доступ к своим личным методам и написать для них тест.

Я использовал Reflection, чтобы получить доступ к своим функциям и написать для них тесты.Вот пример простого частного метода:

 private String myFun (String input){
        return input+"hello";
    }

Существует тестовый класс, в котором я использовал отражение:

@RunWith(AndroidJUnit4.class)
public class NetworkManagerTest {

    private static NetworkManager networkManager;
    private Context appContext = InstrumentationRegistry.getTargetContext();

    private @ADType
    int adType = ADType.TYPE_BANNER;


    @BeforeClass
    public static void setup() {

        getInstrumentation().runOnMainSync(new Runnable() {
            @Override
            public void run() {

                networkManager = NetworkManager.getInstance();
                networkManager.addNetworkCall(TestUtil.getSampleSystemRequest());

            }
        });
    }

    @Test
    public void sample() throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {

        Method method = NetworkManager.class.getDeclaredMethod("myFun", String.class);
        method.setAccessible(true);
        String output = (String) method.invoke(networkManager, "Ehsan");

        Assert.assertEquals("Ehsanhello", output);
    }

}

Это отлично работает.Но вопрос в том, насколько хорошо этот способ написать тест для частных методов с использованием рефлексии?

Есть ли лучший способ достичь этой цели?

Answer 1

Но вопрос в том, насколько хорошо написать тест для приватных методов с использованием отражения?

Есть ли лучший способ достичь этой цели?

Самый распространенный подход - отказаться от этой цели.

Исторически TDD фокусировался на проверке поведения , а не на деталях реализации. Отчасти дело в том, что тесты дают нам свободу уверенно изменять внутренний дизайн кода, потому что тесты будут предупреждать нас о любых непреднамеренных изменениях в поведении.

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

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

Сделав это, у нас есть возможность рефакторинга кода путем встраивания приватного метода; все тесты все равно должны пройти в этом случае, потому что мы не изменили поведение испытуемого - мы просто переместили детали.

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