Тесты JUnit для POJO

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

Я провел два часа из-за чего-то вроде этого:

int getX()
{
    return (x);
}

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

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

Ответ 5

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

Ответ 6

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

Конечно, это все шаблон, поэтому вы можете легко написать script, который генерирует модульные тесты для ваших геттеров и сеттеров, если вы считаете, что там есть какая-либо ценность. Некоторые IDE могут позволить вам определить шаблон, который создает тестовые примеры с тестовыми методами, заполненными для этого шаблона кода (я думаю о IntelliJ здесь, но Eclipse, возможно, тоже справится с этим, хотя я не сделал ничего подобного в любом IDE).

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

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

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

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

Ответ 12

Я экспериментирую с cobatura для покрытия кода и просто сталкивался с той же проблемой.

Было бы неплохо добавить аннотацию к классу, который сказал, что этот класс не включает в покрытие кода. Однако можно поместить ваше pojo в отдельный пакет, а затем исключить этот пакет из анализа.

Смотрите документацию в зависимости от вашего инструмента, она работает с Ant, Maven или командной строкой.

Ответ 13

Я только начал проект, чтобы сделать это. его в пред-альфа-стадии прямо сейчас. Это плагин Eclipse.

Хотя я согласен с тем, что обычно установщик/получатель POJO не обязательно нуждается в тестировании, я считаю, что приятно иметь простой тест там, потому что, поскольку со временем ситуация изменится, вам будет легче добавить больше тестов для POJO. Unit test настроен, методы для тестирования setter/getter, все, что вам нужно сделать, это справиться с новой сложностью.

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

https://sourceforge.net/projects/unittestgplugin/

Ответ 14

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

Таким образом, вам не нужно тестировать их, если у вас нет конкретного требования к equals и hashcode

https://projectlombok.org/

Ответ 15

Unit Test код, который вы хотите знать, работает (для проверяемых ситуаций, конечно). Не используйте unit test код, который вы только хотите быть уверенным в работе.

Я не могу думать о многом, о котором я только хочу быть уверенным.

Ответ 16

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