JUnit: лучшая стратегия размещения тест-методов

Question

Я запустил проект и впервые использую JUnit.

Какова лучшая практика размещения тестовых случаев?

• 1 тестовый класс для каждого "настоящего" класса.

• 1 тестовый класс для каждого пакета или даже всего проекта.

• Методы испытаний в «реальном» классе без тестового класса.

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

EDIT

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

Answer 1

1 тестовый класс для каждого «настоящего» класса.

Обычно я иду по этой схеме. Конечно, тесты для интерфейсов не имеют особого смысла, и бывают случаи, когда небольшие классы «сущностей» только с методами getter и setter (то есть без логики) не нуждаются в соответствующем классе теста.

Тем не менее, я был удивлен тем, какую полезность я нашел в модульных тестах даже для очень маленьких классов. Например, даже классы сущностей, имеющие только методы get / set, которые хранятся в базах данных с помощью методов DAO, должны быть протестированы на случай, если какая-то из проводок базы данных неверна. Вы никогда не знаете, когда у вас есть несоответствующий метод get / set, или toString(), асимметричный hashcode() или equals(), или другие проблемы.

Весь смысл «модульных» тестов заключается в (ИМХО) тестировании самого маленького модуля вашего кода изолированно - это класс. Поэтому, когда у меня есть класс ContainerUtil, я ищу соответствующий класс ContainerUtilTest в тестовом каталоге. Я часто запускаю тесты покрытия и ожидаю, что будут покрыты практически все логические части всех классов.

1 тестовый класс для каждого пакета или даже всего проекта.

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

Но это будет в дополнение к вашим юнит-тестам.

Методы испытаний в «реальном» классе без класса испытаний.

Да, нет. Действительно плохая идея. Вы не хотите, чтобы ваш производственный код включал тестовый код, если это вообще возможно. Это уменьшает читабельность ваших классов, увеличивает изменения, которые вы что-то ломаете при попытке проверить и т. Д. Просто скажите нет.

Я также держу свои тестовые классы подальше от источников. Я обычно использую maven, поэтому мои источники находятся в src/main/java, а мои тесты - в src/test/java. Вы не хотите, чтобы ваши тесты попали в файлы jar или war, где они могут запутать других.

Answer 2

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

Кроме того, я настоятельно рекомендую вам применить TDD для разработки своего кода: сначала вы пишете свой тестовый код для сбоя, затем вы пишете код для прохождения теста и затем выполняете рефакторинг.

Позвольте мне предложить вам два источника чтения:

• Разработка через тестирование: по примеру
• Рефакторинг: улучшение дизайна существующего кода

Это те же ресурсы чтения, которые я использовал для создания тестов и использования TDD.

Я не рекомендую вам использовать другие подходы, так как вам не нужно отправлять тестовый код в производство, и использование одного тестового класса вызовет запах кода, известный как «Большой класс».

Answer 3

Для модульного тестирования я до сих пор использовал один тестовый класс для каждого тестируемого класса.Для меня это казалось наименее грязным порядком.Я поместил модульные тесты в src / test / java в то же дерево пакетов, что и тестируемые классы в src / main / java.Интеграционные тесты различны и имеют свои собственные файлы.

Один тестовый класс имеет свои недостатки.Исходный код станет нечитаемым.Вы будете выполнять много ненужной работы в методах @Before и @BeforeEach.

И у меня нет смысла помещать тесты в тестируемый класс.Много импорта, и чем бы вы отличались между «реальными» и тестовыми методами?А из-за дополнительных методов исходный код станет нечитаемым.

Answer 4

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

О других 2:

1 тестовый класс для каждого пакета или даже всего проекта.

Это может стать большим и грязным, не рекомендую смешивать разные вещи в одном и том же тестовом классе, так же, как вы не смешиваете классы в одном и том же файле

Методы испытаний в «реальном» классе без тестового класса.

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