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

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

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

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

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

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

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

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

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

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...

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

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

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

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

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

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

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

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