У меня есть 2 вопроса об организации модульных тестов.
Должен ли я поместить тест в тот же пакет, что и проверенный класс, или я могу организовать тесты в разных пакетах?
Например, если у меня есть тесты достоверность и другие, правильно ли их разбить на разные пакеты, даже если они предназначены для одного класса?
Как насчет макетов и заглушек? Должен ли я отделить их от пакетов, содержащих только тесты, или собрать их вместе?
То, как мы делаем наши тестовые примеры JUnit, состоит в том, чтобы поместить их в один и тот же пакет, но в другой корневой каталог. Поскольку мы используем Maven, мы просто используем стандартные расположения, которые делают структуру похожей на следующую.
src/main/java/com/foo/Bar.java
src/test/java/com/foo/BarTest.java
Очевидно, что в структуре больше, но это позволяет нам строить тесты отдельно от кода основной линии, но все же доступ к защищенным классам и тому подобное. Что касается различных типов тестов, это очень субъективно. Когда мы начали тестирование (которое, к сожалению, началось после разработки), я старался держать вещи довольно изолированными. К сожалению, это быстро стало кошмаром, когда мы добрались до 500 + контрольных точек. С тех пор я попытался сделать больше консолидации. Это привело к уменьшению количества кода для поддержания. Как я уже сказал, это очень субъективно.
Что касается тестового кода, мы сохраняем его в отдельном пакете com.foo.test, который находится только в дереве src/test/java.
Тестовые классы должны быть скорее в разных пакетах, тем легче их отделить от производственного кода при его упаковке для выпуска. Я обычно держу много пробного пуха в этих пакетах, всевозможные макеты, конфигурации, сценарии. Но когда вы строите - это не получается. В некоторых ситуациях рекомендуется хранить ваши тестовые материалы даже в разных проектах. Зависит.
Я тоже склонен ставить свои тесты в один и тот же пакет, но в другом корневом каталоге. Это позволяет мне тестировать частные классы класса или получать доступ к классам, приватным к упаковке, при тестировании чего-то еще в пакете. Они хранятся в отдельном дереве каталогов, чтобы исключить их из развернутого результата (в частности, чтобы убедиться, что тестовый код случайно не попал в производственный код). Самое главное, однако, то, что работает для вашей ситуации.
В терминах количества тестовых классов для производственного класса теория, которую я видел, заключается в том, что вы пишете один тестовый класс для каждого прибора, то есть для каждой структуры установки. Во многих случаях это одно и то же (или достаточно близко) к одному тестовому классу для каждого производственного класса, но я иногда писал больше тестовых классов (в частности, тесты на равенство, как правило, разделяются) для производственного класса, а иногда и один тестовый класс для группы (связанных) производственных классов (например, для тестирования шаблона стратегии).
В основном, я не слишком беспокоюсь об этой теории, но переделываю тесты по мере необходимости, чтобы сохранить дублирование до абсолютного минимума.
Сохранение одного и того же пакета позволяет использовать прозрачность для пакета для кода, который предназначен для доступа только через тест.
Что касается использования отдельных корневых каталогов, это хорошая практика. Он также имеет преимущество для нас, поскольку мы используем IDEA, IDEA признает, что производственный код не может ссылаться на тестовый код.
С точки зрения сохранения их отдельно, существует большая сила в наличии одного и только одного тестового класса для производственного класса на уровне единицы. Конечно, некоторые классы создаются в производстве как часть рефакторинга, которые вообще не имеют тестовых классов, и это нормально, но когда вы хотите знать, какие тесты тестируют определенный класс, имея соглашение, в котором говорится, что ClassNameTest - это тесты для ClassName очень полезно.
TestNG гораздо более дружелюбен к этой парадигме, чем JUnit.