Создание тестов nunit без экспорта их с API

Question

Я новичок в модульном тестировании с использованием nunit (и разработки на Java в целом). При создании модульных тестов для закрытых методов в классах создается впечатление, что тестовый файл должен находиться в том же пакете, что и тестируемый класс. Каков типичный способ избежать экспорта API модульных тестов? Могу ли я сделать классы / методы тестирования защищенными? Или разработчики, как правило, имеют отдельную сборку для выпуска, исключающую файлы модульных тестов?

Answer 1

Я могу сказать IntelliJ или Ant не упаковывать тесты JUnit при развертывании. У меня есть тесты в отдельном каталоге от исходного кода, что делает это возможным.

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

Answer 2

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

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

src/main/java/com/example/Foo.java
src/test/java/com/example/FooTest.java

Тогда ваш скрипт сборки может очень просто проигнорировать src/test/**, когда придет время для упаковки и развертывания.

Answer 3

Хранить исходный код теста вне исходного кода приложения. В общем, только тестирование выставленной функциональности. Если вам действительно нужно протестировать приватное поведение, создайте тестовый объект, который расширяет реальный объект и предоставляет доступ publec к приватному поведению.

Answer 4

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

Это обычно приводит к тому, что мой дизайн содержит небольшие классы с четко определенной функциональностью, которые легче тестировать.

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

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

Answer 5

Тестовый файл не обязательно должен быть в том же пакете, что и тестируемый класс. На самом деле, рекомендуется иметь тестовые файлы в отдельном пакете, что позволяет им тестировать общедоступный API, не заботясь о деталях реализации на уровне пакета.

Кроме того, вы можете настроить скрипт сборки (например, Nant) так, чтобы при сборке исполняемого файла выпуска игнорировались файлы, содержащие «Test»