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

118

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

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

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

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

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

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


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

Ricket
источник
1
возможный дубликат Где мне разместить тесты JUnit?
mmmmmm 07

Ответы:

154

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

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 и не могу сравнить их.) Одно можно сказать наверняка: это делает модульное (и интеграционное) тестирование естественным первоклассным шагом в процессе, который помогает разработчикам принять эту важную практику.

Петер Торок
источник
6
Я тоже согласен с суффиксом. Кроме того, поскольку тестовые классы разделены в другую физическую папку, нет необходимости пытаться использовать префикс Test в попытке обмануть сортировку в алфавитном порядке в группировку, и я думаю, что SomeClassTest лучше читается.
Ricket
Отличные съезды +1
вискисьерра
1
Одна вещь о помещении тестовых классов в один и тот же пакет: хотя он позволяет использовать частные члены пакета (поэтому я тоже использую эту схему), он также не позволяет автоматически тестировать видимость, особенно. если вы используете TDD и позволяете вашей среде IDE генерировать необходимые заглушки методов. Он может генерировать их с видимостью, закрытой для пакета (NetBeans, я смотрю на вас), что делает ваш тест идеальным (после того, как вы фактически поместили реализацию в эти заглушки), но может не работать в реальном использовании (если вы забыли добавить public) ,
Сергей Таченов
Хотя это соглашение интересно, что вы будете делать, когда набор тестов вырастет? Например, допустим, у вас есть 6 методов в классе, каждый метод имеет 10 тестов. В вашем классе 60 тестов? Обычно я разделяю тестовый класс (один тестовый класс на метод). Проблема в том, что в тестовом пакете вы можете найти много классов.
mmalmeida
1
@Thick_propheT в Eclipse: щелкните правой кнопкой мыши имя проекта, выберите «Создать» - «Другое» ..., затем внутри папки Java выберите «Исходная папка». назовите это "тест". Затем, если вы хотите следовать приведенному выше соглашению, добавьте новый пакет в эту тестовую папку с тем же именем, что и пакет класса, для которого вы хотите написать тестовый пример, затем в пакет добавьте новый тестовый пример JUnit (расположенный в папку Java / Junit, когда вы делаете New-Other ...). в этом новом мастере вы можете указать тестируемый класс и назвать свой тестовый пример таким же именем с суффиксом «Test»
или
15

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

ChrisH
источник
12

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

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

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

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

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

Мартин
источник
18
Я думал, что это было <class>Test.java, а неTest<class>.java
Майк Райландер
2
Maven примет любой шаблон в соответствии с документацией плагина Maven Surefire .
Элайджа Вудворд
3
Я бы сказал, что <class>Test.javaсхема именования приближает и основной, и тестовый классы при использовании функций поиска IDE, что делает его немного лучше, чем Test<class>.java.
christopheml
1
@christopheml Я согласен, вот чем я сейчас занимаюсь.
Мартин
Это сработало для Intellij. MyClassTest.java не работал.
user2761431