Тесты JUnit для POJO

Question

Я работаю над проектом, в котором мы должны создать модульные тесты для всех наших простых bean-компонентов (POJO). Есть ли смысл создавать модульный тест для POJO, если они состоят только из геттеров и сеттеров? Является ли безопасным предположение, что POJO будут работать примерно в 100% случаев?

---

Дубликат - Следует ли проверять @Entity Pojos?

См. Также

Это плохая практика - запускать тесты на БД, а не на поддельных репозиториях?

Существует ли инфраструктура модульного тестирования Java, которая автоматически тестирует геттеры и сеттеры?

Answer 1

Правило в TDD: "Проверьте все, что может сломаться" Может ли геттер сломаться? Как правило, нет, поэтому я не пытаюсь проверить это. Кроме того, код I do test обязательно вызовет геттер, поэтому он будет проверен.

Мое личное правило - я напишу тест для любой функции, которая принимает решение или выполняет не просто тривиальные вычисления. Я не буду писать тест для i+1, но я, вероятно, буду для if (i<0)... и определенно буду для (-b + Math.sqrt(b*b - 4*a*c))/(2*a).

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

Answer 2

POJO могут также содержать другие функции, такие как equals (), hashCode (), compareTo () и различные другие функции. Может быть полезно знать, что эти функции работают правильно.

Answer 3

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

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

Answer 4

Однажды я провел два часа из-за чего-то вроде этого:

int getX()
{
    return (x);
}

int getY()
{
    return (x); // oops
}

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

Answer 5

Я использую IntelliJ в качестве IDE, и он в значительной степени пишет для меня тривиальные POJO - конечно, конструктор и методы получения / установки. Я не вижу смысла в модульном тестировании, так как любые ошибки, скорее всего, будут в тестовом коде, который я пишу.

Answer 6

IMHO POJO автоматически проверяются при проверке логики для любой функциональности, например Для тестирования любых функций нам может потребоваться ввести / смоделировать определенные значения, POJO и методы получения / установки для POJO тестируются косвенно.

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

1. ИСПОЛЬЗОВАТЬ БИБЛИОТЕКУ: использовать существующие библиотеки, которые помогают тестировать POJO. Одна из таких библиотек, с которой я столкнулся, - скупой.

   Ссылка : http://meanbean.sourceforge.net/

   Maven : http://mvnrepository.com/artifact/org.meanbean/meanbean (текущая версия: 2.0.3)

2. IGNORE POJO: Sonar можно настроить так, чтобы исключить POJO или конкретные пакеты, которые будут исключены из отчетов о покрытии модульных испытаний. Несколько примеров ниже:

   <properties>
       <sonar.coverage.exclusions>
           **/domain/**/*,
           **/pojos/*
       </sonar.coverage.exclusions>
   </properties>
   

Answer 7

Существует утилита с открытым исходным кодом http://meanbean.sourceforge.net/, которая позволяет вам тестировать POJO. Есть также страница, которая описывает достоинства / вопросы, которые могут возникнуть у пользователя относительно того, что предлагает эта утилита и почему ее следует использовать.

Я никогда не уставал сам (пока), но это было рекомендовано мне.

Answer 8

Модульные тесты не только проверяют правильность работы кода, но и документируют ожидаемое поведение. Я не знаю, сколько раз я видел, как что-то сломалось, потому что какое-то время в будущем кто-то меняет поведение метода получения или установки в POJO, а затем неожиданно нарушает что-то другое (например, кто-то добавляет логику в средство установки что если кто-то установит нулевое значение в строке, установщик изменит его на пустую строку, чтобы не возникали NPE).

Я не рассматриваю модульные тесты в POJO хранилища данных как пустую трату времени, я вижу их в качестве защитной сетки для будущего обслуживания. При этом, если вы пишете тесты для проверки этих объектов вручную, вы делаете это трудным путем. Взгляните на что-то вроде http://gtcgroup.com/testutil.html

Answer 9

Вероятно, стоит провести простой тест, чтобы убедиться, что вы не написали

public void setX(int x) {
   x = x;
}

Хотя вам следует кодировать, чтобы этого избежать (поместив модификатор final в параметр метода или аналогичный). Это также зависит от того, как вы генерируете свои методы доступа и могут ли они пострадать от ошибок копирования / вставки и т. Д. (Это будет происходить даже в средах, которые пытаются принудительно использовать IDE - просто так)

Моя главная проблема с классами, содержащими множество методов установки / получения, однако, что делает класс ? Объекты должны делать что-то для вас, а не просто хранить и возвращать данные. Если это объекты сущности данных, то шаблон установщика / получателя может быть правильным. Однако лучше всего установить данные в объекте и попросить объект что-то с ним сделать (вычислить баланс банка, запустить ракету и т. Д.), А не возвращать данные и позволить вам сделать это самостоятельно!

Answer 10

По моему опыту, создание модульных тестов для POJO только с геттерами и сеттерами просто излишне. Конечно, есть некоторые исключения, если в getter / setter есть дополнительная логика, такая как проверка на ноль и выполнение чего-то особенного, чем я бы создал для этого модульный тест.

Кроме того, если в POJO есть ошибка, я бы создал для нее модульный тест, чтобы мы могли предотвратить ее повторение.