JUnit тестирует на POJOs

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

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

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

По моему опыту, создавая модульные тесты на POJOs только с методами считывания и методами set, просто излишество. Существуют некоторые исключения, конечно, если бы существует дополнительная логика в методе считывания/методе set как проверка пустой указатель и выполнение чего-то специального, чем я создал бы модульный тест на это.

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

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

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

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

int getX()
{
    return (x);
}

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

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

Я не думаю, что существует точка к тестированию простых методов считывания свойства и методов set. Точка поблочного тестирования не должна проверять, что Ваш компилятор работает.

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

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

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

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

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

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

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

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

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

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

Я только что начал проект для этого. Сейчас он находится на стадии пре-альфа. Это плагин для Eclipse.

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

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

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