Как я тестирую локальные внутренние методы класса в Java? [дубликат]
5 ответов
Филиппо, я понимаю ваше разочарование по поводу проблемы и некоторых ответов. Когда я впервые начал использовать JUnit много лет назад, я тоже хотел протестировать частный код, и мне показалось глупым со стороны гуру говорить, что это плохая идея.
Оказывается, они были правы (сюрприз!), Но только после написания нескольких тестов я понял , почему . Возможно, вам придется пройти через тот же процесс, но в конечном итоге вы придете к такому же выводу; -)
В любом случае, в вашей ситуации я бы сделал Nested подходящим автономным классом, возможно, в отдельном классе. отдельный пакет, чтобы было очевидно, что это вспомогательные классы. Затем я бы написал тесты для него напрямую, независимо от каких-либо других тестов.
Затем я бы написал тесты для NewStyle и сосредоточился только на поведении NewStyle .
(Вполне вероятно, что я бы также вставил Вложенный в NewStyle , а не создавал его в NewStyle , т. Е. Сделал бы его аргументом для NewStyle .
Затем, когда я пишу тесты для NewStyle в тесте, я передаю экземпляр Nested и продолжаю. Если я чувствовал себя особенно сложно, Я бы создал интерфейс из Nested и создал вторую реализацию, а также протестировал бы NewStyle с этим.)
Вам следует избегать чрезмерного усложнения кода только потому, что вы
не хотите, чтобы методы
В вашем случае вы можете протестировать методы, если они являются методами внешнего класса или если вам абсолютно необходим внутренний класс, поместите его вне метода mainAlg (), чтобы он был виден глобально.
public class NewStyle {
public int mainAlg() {
Nested n = new Nested();
int x = n.subAlg01();
int y = n.subAlg02();
int z = x * y;
return z;
}
class Nested {
public int subAlg01() {
return 3;
}
public int subAlg02() {
return 5;
}
}
}
это можно затем вызвать с помощью new NewStyle (). New Nested (). SubAlg01 ();
Хм, я знаю, что такие языки, как Groovy, часто используются для модульного тестирования на Java и могут прозрачно получать доступ к закрытым полям и методам ... но я не уверен насчет этого вложенные классы. Я могу понять, почему вы можете захотеть делать такие вещи, но я как бы занимаю ту же позицию, что и при тестировании геттеров и сеттеров, их следует тестировать как побочный эффект тестирования ваших общедоступных методов, а если они этого не делают пройти тестирование таким образом, тогда зачем они вообще здесь?
Вы должны тестировать только открытый интерфейс классов, но не частные члены или частные внутренние классы. Частные члены должны быть деталями реализации, используемыми только общедоступными методами класса (прямо или косвенно). Таким образом, вы можете провести модульное тестирование косвенно с помощью методов вызывающего объекта. Если вы чувствуете, что у вас недостаточно детализации в этих модульных тестах или что вы не можете ощутить (некоторые) результаты, которые вас интересуют, это, вероятно, указывает на проблему с вашим дизайном: класс может быть слишком большим, пытаясь делать слишком много, поэтому некоторые из его функциональных возможностей, возможно, придется выделить в отдельный класс, где затем их можно будет протестировать напрямую.
В текущем примере, если сам внутренний класс содержит много кода, вы можете просто превратить его в класс верхнего уровня, а затем напрямую выполнить модульное тестирование его методов.
(Между прочим, ваш внутренний класс должен быть статическим , если ему не нужно ссылаться на экземпляр включающего класса.)
Вы не можете получить доступ к этим классам извне, так что юнит не может их проверить. Вы должны иметь что-то публичное, чтобы Их проверять.