Поділ класів JUnit на спеціальний тестовий пакет?

Я вивчаю концепції тестово-керованого розвитку, читаючи статті про майстра (натисніть Майстер під Темою ), рекомендовані у відповіді на моє попереднє запитання "Приклад проекту для вивчення JUnit та належної інженерії програмного забезпечення" . Я люблю це поки!

Але зараз я хочу сісти і спробувати сам. У мене є питання, на яке, сподіваюся, знадобиться лише проста відповідь.

Як ви організовуєте свої тестові класи JUnit та власний код? Я кажу в основному про структуру пакету, але будь-які інші поняття примітки також були б корисні.

Ви ставите тестові класи в org.myname.project.test. * І звичайний код в org.myname.project. *? Ви ставите тестові класи поряд із звичайними заняттями? Ви віддаєте перевагу префіксам імен класів за допомогою тесту, а не суфіксам?

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

І у мене є проект, який зараз акуратно розділений на пакети, але проект став безлад. Замість того, щоб намагатися рефакторировать все і писати тести, я хочу почати свіжий, тести насамперед. Але спочатку мені потрібно знати, куди йдуть мої тести.

редагувати: Я повністю забув про Мейвен, але, здається, більшість з вас це використовує! У минулому у мене був конкретний випадок, коли Мейвен повністю зірвався на мене, але Ент надав мені потрібну гнучкість, тому я опинився прив’язаним до Мурахи, але я думаю, що, можливо, я просто прийняв неправильний підхід. Я думаю, я спробую ще раз спробувати 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, але, здається, є принаймні стільки, хто цього не робить. IMHO - це дуже корисно для «основних» Java-проектів (я б поставив близько 90% проектів у цю категорію ... але інші 10% все ще значну меншину). Вона проста у використанні, якщо можна прийняти конвенції Мейвена; проте якщо ні, то це робить життя нещасною боротьбою. Мавен, здається, важко зрозуміти для багатьох людей, соціалізованих на Мурашника, оскільки, мабуть, це вимагає зовсім іншого способу мислення. (Я сам, ніколи не використовував Ant, не може порівняти обидва.) Одне можна точно: це робить тестування (та інтеграція) тестуванням природним, першокласним кроком у процесі, що допомагає розробникам прийняти цю необхідну практику.

Я кладу свої тестові класи в той же пакет, що і тестування, але в іншу папку чи проект . Організуючи свій тестовий код таким чином, я можу легко компілювати та упаковувати його окремо, щоб файли виробничих jar не містили тестового коду. Він також дозволяє тестовому коду отримувати доступ до приватних полів та методів пакету.

Я використовую Maven . Структура, яку Maven просуває, є:

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

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

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

Однією з переваг наявності тестових класів у тому самому пакеті (не обов'язково в каталозі) є те, що ви можете використовувати методи-пакети для перевірки або введення макетних тестових об'єктів.