Разделение классов JUnit в специальный тестовый пакет?

Question

Я изучаю концепции разработки через тестирование, прочитав Статьи мастера (нажмите Мастер в разделе По теме ), рекомендуемые в ответе на мои предыдущие вопрос, «Пример проекта по изучению JUnit и правильной программной инженерии» . Я люблю это до сих пор!

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

Как вы организуете свои тестовые классы JUnit и ваш реальный код? Я говорю в основном о структуре пакета, но любые другие заметные концепции также будут полезны.

Помещаете ли вы тестовые классы в org.myname.project.test. * И обычный код в org.myname.project. *? Вы ставите тестовые классы рядом с обычными классами? Предпочитаете ли вы префикс имен классов с помощью Test, а не суффикс их?

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

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

---

edit: Я полностью забыл о Maven, но, похоже, большинство из вас его использует! В прошлом у меня был конкретный случай использования, когда Maven полностью сломался, но Ant предоставил мне необходимую гибкость, поэтому я в итоге присоединился к Ant, но я думаю, что, возможно, я просто выбрал неправильный подход. Я думаю, что я попробую Maven еще раз, потому что похоже, что это будет хорошо с разработкой, управляемой тестами.

Answer 1

Я предпочитаю помещать тестовые классы в тот же пакет, что и классы проектов, которые они тестируют, но в другом физическом каталоге, например:

myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java

В проекте Maven это будет выглядеть так:

myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java

Суть в том, что мои тестовые классы могут обращаться (и тестировать!) К классам и членам области действия пакета.

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

Обновление на основе комментария @ Рикета: таким образом, тестовые классы (как правило) появляются сразу после своего проверенного друга в алфавитном списке проектов по названиям классов. (Забавно, что я извлекаю пользу из этого изо дня в день, не осознавая, как ...)

Обновление 2: Многим разработчикам (включая меня) нравится Maven, но, похоже, есть как минимум столько же, кто этого не делает. ИМХО, это очень полезно для "основных" Java-проектов (я бы отнес около 90% проектов в эту категорию ... но остальные 10% все еще составляют значительное меньшинство). Его легко использовать, если принять соглашения Maven; однако, если нет, это делает жизнь жалкой борьбой. Многим людям, общавшимся с Ant, кажется, трудно понять Maven, так как он, очевидно, требует совершенно другого мышления. (Я сам, никогда не использовавший Ant, не могу сравнить два.) Одно можно сказать наверняка: он делает модульное (и интеграционное) тестирование естественным, первоклассным шагом в процессе, который помогает разработчикам принять эту важную практику.

Answer 2

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

Answer 3

Я использую Maven . Структура, которую продвигает Maven: -

src/main/java/org/myname/project/MyClass.java

src/test/java/org/myname/project/TestMyClass.java

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

Одним из преимуществ наличия тестовых классов в одном пакете (но не обязательно в каталоге) является то, что вы можете использовать методы области действия пакета для проверки или внедрения фиктивных тестовых объектов.