Где я должен поставить свои тесты JUnit?

Question

У меня есть 2 вопроса об организации юнит-тестов.

<Ол>

Нужно ли ставить тест в тот же пакет, что и тестируемый класс, или я могу организовать тесты в разных пакетах?

Например, если у меня есть тесты validity и other , правильно ли разделять их на разные пакеты, даже если они для одного класса?

А как насчет ложных и тупых классов? Должен ли я отделить их от пакетов, содержащих только тесты, или собрать их вместе?

Answer 1

То, как мы выполняем наши тестовые примеры JUnit, - это помещать их в один и тот же пакет, но в другой корневой каталог. Поскольку мы используем Maven, мы просто используем стандартные местоположения, делая структуру похожей на следующую.

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

Очевидно, что это еще не все в структуре, но это позволяет нам создавать тесты отдельно от основного кода, но при этом получать доступ к защищенным классам и тому подобное. Что касается разных типов тестов, это очень субъективно. Когда мы начали тестирование (которое, к сожалению, началось после разработки), я старался держать вещи в изоляции. К сожалению, это быстро стало кошмаром, когда мы добрались до контрольной точки 500+. С тех пор я пытался сделать больше консолидации. Это привело к уменьшению количества кода для поддержки. Как я уже сказал, это очень субъективно.

Что касается кода только для тестирования, мы храним его в отдельном пакете com.foo.test , который находится только в дереве src / test / java .

Answer 2

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

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

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

Answer 3

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

Answer 4

Сохранение его в одном и том же пакете позволяет использовать частную видимость пакета для кода, доступ к которому предназначен только через тест.

Что касается использования отдельных корневых каталогов, это хорошая практика. Это также имеет для нас преимущество, поскольку мы используем IDEA, IDEA признает, что производственный код не может ссылаться на тестовый код.

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

TestNG гораздо более дружелюбен к этой парадигме, чем JUnit.