Попробовав решение Cem Catikkas , использующее рефлексию для Java, я бы сказал, что это было более элегантное решение, чем я описал здесь. Однако, если вы ищете альтернативу использованию отражения и имеете доступ к тестируемому источнику, это все равно будет вариант.
Возможно, есть смысл в тестировании частных методов класса, особенно при разработке, управляемой тестами , где вы хотели бы создавать небольшие тесты перед написанием любого кода.
Создание теста с доступом к закрытым членам и методам может тестировать области кода, на которые сложно ориентироваться конкретно, имея доступ только к открытым методам. Если открытый метод включает несколько этапов, он может состоять из нескольких частных методов, которые затем можно протестировать по отдельности.
Преимущества:
- Может тестировать до более мелкой зернистости
Недостатки:
- Тестовый код должен находиться в том же
файл в качестве исходного кода, который может быть
более сложный в обслуживании
- Точно так же с выходными файлами .class они должны оставаться в том же пакете, который объявлен в исходном коде
Однако, если этот метод требует непрерывного тестирования, это может быть сигналом того, что частные методы должны быть извлечены, что может быть протестировано традиционным, общедоступным способом.
Вот замысловатый пример того, как это будет работать:
// Import statements and package declarations
public class ClassToTest
{
private int decrement(int toDecrement) {
toDecrement--;
return toDecrement;
}
// Constructor and the rest of the class
public static class StaticInnerTest extends TestCase
{
public StaticInnerTest(){
super();
}
public void testDecrement(){
int number = 10;
ClassToTest toTest= new ClassToTest();
int decremented = toTest.decrement(number);
assertEquals(9, decremented);
}
public static void main(String[] args) {
junit.textui.TestRunner.run(StaticInnerTest.class);
}
}
}
Внутренний класс будет скомпилирован в ClassToTest$StaticInnerTest
.
См. Также: Java Совет 106: Статические внутренние классы для удовольствия и прибыли