Почему нам нужны тестовые примеры для запуска против простых POJO

Question

При написании тестов junit я не могу не думать, что тесты Junit подходят для классов с методами, которые выполняют много бизнес-логики. Таким образом вы записываете условия тестирования для проверки каждого блока if-else.

Но в корпоративном приложении, которое имеет много java beans, почему junit нужно запускать против них? Кажется излишним написать тестовый пример для стандартного getter/setter, который не выполняет никакой логики или вычисления.

Должен ли junit быть не только для классов с бизнес-логикой и не просто POJO?

Answer 1

POJO не означает «класс без бизнес-логики», это означает, что класс не имеет зависимости от инфраструктуры или структуры. (Некоторые структуры, использующие POJO, такие как Hibernate и Spring, поощряют своих пользователей к тому, чтобы их POJO соответствовали некоторым соглашениям JavaBean, главным образом, именованию геттеров и сеттеров.) Весомые услуги - это POJO (или близкие к POJO, некоторые могут думаю, введение аннотаций было шагом от чистоты POJO), и у них есть бизнес-логика.

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

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

Answer 2

FYI, я создал фреймворк, размещенный на GitHub для автоматического тестирования геттеров/сеттеров.

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

GetterSetterTester проверяет отдельные поля.

ReflectionGetterSetterTester проверить все поля в классе.