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

Question

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

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

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

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

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

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

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

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

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

Answer 4

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