Это - плохая практика для использования Отражения в Поблочном тестировании? [дубликат]

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

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

Например, в Spring есть ReflectionTestUtils. Но его цель - установить макеты зависимостей там, где Spring должен был их инжектировать.

Тема глубже, чем "делать и не делать", и касается чего следует тестировать - нужно ли тестировать внутреннее состояние объектов или нет; должны ли мы позволить себе подвергать сомнению дизайн тестируемого класса; и т.д.

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

Не зная больше о вашем случае, я не могу сказать больше, но использование reflection действительно считается плохой практикой. Лично я предпочел бы сделать тест статическим внутренним классом тестируемого класса, чем прибегать к отражению (если, скажем, нетестируемая часть API не находится под моим контролем), но в некоторых местах будет больше проблем с тем, что тестовый код находится в том же пакете, что и рабочий код, чем с использованием отражения.

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

В любом случае, вы можете обойти эту проблему, используя protected (к сожалению, не package-private, который действительно идеален для этого), тестируя подкласс следующим образом:

 public class ClassUnderTest {
      protect void methodExposedForTesting() {}
 }

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

class ClassUnderTestTestable extends ClassUnderTest {
     @Override public void methodExposedForTesting() { super.methodExposedForTesting() }
}

И если у вас есть защищенный конструктор:

ClassUnderTest test = new ClassUnderTest(){};

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

С точки зрения TDD - Test Driven Design - это плохая практика. Я знаю, что вы не помечали этот TDD и не спрашивали об этом конкретно, но TDD - хорошая практика, и это идет вразрез с ее сущностью.

В TDD мы используем наши тесты для определения интерфейса класса - общедоступного интерфейса - и поэтому мы пишем тесты, которые напрямую взаимодействуют только с общедоступным интерфейсом. Нас интересует этот интерфейс; соответствующие уровни доступа - важная часть дизайна, важная часть хорошего кода. Если вам нужно протестировать что-то личное, обычно, по моему опыту, это запах дизайна.

Чтобы добавить к сказанному другими, рассмотрим следующее:

//in your JUnit code...
public void testSquare()
{
   Class classToTest = SomeApplicationClass.class;
   Method privateMethod = classToTest.getMethod("computeSquare", new Class[]{Integer.class});
   String result = (String)privateMethod.invoke(new Integer(3));
   assertEquals("9", result);
}

Здесь мы используем отражение для выполнения частного метода SomeApplicationClass.computeSquare (), передавая Integer и возвращая результат String. Это приводит к тесту JUnit, который будет компилироваться нормально, но завершится неудачно, если произойдет одно из следующих событий:

• Имя метода "computeSquare" переименовано
• Метод принимает другой тип параметра (например, изменение Integer на Long)
• Число изменяемых параметров (например, передача другого параметра)
• Тип возвращаемого значения метода изменяется (возможно, с String на Integer)

Вместо этого, если нет простого способа доказать, что computeSquare сделал то, что предполагается, что это делается через общедоступный API, тогда ваш класс, вероятно, пытается многое сделать. Переместите этот метод в новый класс, который даст вам следующий тест:

public void testSquare()
{
   String result = new NumberUtils().computeSquare(new Integer(3));
   assertEquals("9", result);
}

Теперь (особенно, когда вы используете инструменты рефакторинга, доступные в современных IDE), изменение имени метода не влияет на ваш тест (поскольку ваша IDE также будет также провели рефакторинг теста JUnit), при изменении типа параметра, количества параметров или возвращаемого типа метода будет отмечена ошибка компиляции в вашем тесте Junit, что означает, что вы не будете проверять тест JUnit, который компилируется, но не выполняется во время выполнения .

И наконец, я хочу сказать, что иногда, особенно при работе с устаревшим кодом, когда вам нужно добавить новые функции, это может быть нелегко сделать в отдельном тестируемом, хорошо написанном классе. В этом случае я бы порекомендовал изолировать новые изменения кода в защищенных методах видимости, которые вы можете выполнять непосредственно в тестовом коде JUnit.Это позволяет вам начать создание базы тестового кода. В конце концов вам следует провести рефакторинг класса и извлечь добавленную функциональность, но тем временем защищенная видимость вашего нового кода иногда может быть вашим лучшим способом продвижения вперед с точки зрения тестируемости без серьезного рефакторинга.

Я думаю, что ваш код должен быть протестирован двумя способами. Вы должны протестировать ваши публичные методы с помощью Unit Test, и это будет действовать как тестирование черного ящика. Поскольку ваш код разбит на управляемые функции (хороший дизайн), вы захотите протестировать отдельные части с помощью рефлексии, чтобы убедиться, что они работают независимо от процесса, единственный способ, который я могу придумать, это сделать это с помощью рефлексии, поскольку они приватны.

По крайней мере, так я думаю в процессе модульного тестирования.