Создание nunit-тестов без их экспорта с помощью API

Question

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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