Кто-нибудь делает тестовые случаи для pojos? - PullRequest
4 голосов
/ 18 сентября 2008

Это нужно?

Ответы [ 16 ]

7 голосов
/ 18 сентября 2008

Я пишу явные тесты для всего, кроме простых методов получения и установки.

Если геттер или сеттер содержит только ответный бла; или this.blah = бла; Я не думаю, что есть большая ценность. В большинстве случаев они генерируются, и я чувствую, что время, проведенное вместе, может быть лучше проведено в другом месте

4 голосов
/ 18 сентября 2008

Я думаю, что вопрос немного запутан относительно терминологии. POJO (обычный старый объект Java) относится к объекту Java, не обремененному зависимостями от конкретных серверов приложений или сторонних библиотек. Использование хорошей инфраструктуры IOC (Inversion Of Control), такой как Spring, позволяет записывать все ваши классы как POJO, чтобы вы могли тестировать их независимо, не запуская сервер приложений в тесте.

Java-бин - это простой Java-класс, содержащий закрытые атрибуты и общедоступные методы доступа getBlah () и setBlah () и не более того. Java-бобы по своей природе являются POJO.

Так что, если вопрос был "Должен ли я тестировать свои POJO (которые содержат бизнес-логику)?" ответ решительно да.

Если вопрос таков: «Должен ли я тестировать мои Java-бины (которые являются простыми объектами-значениями без поведения)?» ответ, вероятно, нет.

2 голосов
/ 18 сентября 2008

Легко сказать "Конечно". Вот почему, однако: в реальном программном обеспечении у вас есть слой за слоем компонентов. Легко сказать, что ваши крошечные pojos в нижней части стека слишком малы, чтобы иметь реальные ошибки, но когда вы испытываете неожиданные результаты в программном обеспечении и добавляете весь код, который не был тщательно протестирован, вы в конечном итоге с целой кучей подозреваемых Дженга.

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

Также имейте в виду, что написание тестов для ваших pojos должно быть относительно простым, потому что чем меньше функциональных возможностей предоставляет модуль, тем меньше остается тестировать.

Я согласен не тестировать геттеры и сеттеры.

2 голосов
/ 18 сентября 2008

Если ваши PoJos содержат логику, которая важна для вашего бизнеса, тогда да, конечно, проверьте их.

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

1 голос
/ 21 ноября 2010

Ну, есть еще одно измерение, которое Люди, похоже, упустили.

Да, когда вы думаете о POJO, единственное, что приходит в голову, это свойства с соответствующими геттерами и сеттерами. Но, кроме этого, POJO также может вносить одинаковый вклад в коллекцию с помощью переопределенных методов equals () и hashCode (). :) В таком случае мой POJO заслуживает достойного тестирования! :)

Вы должны проверять различные времена с разными возможными значениями и убедиться, что комбинация equals () и hashCode () НЕ предоставляет дублирующихся значений!

1 голос
/ 18 сентября 2008

Итак, как уже упоминали все остальные, да, вам нужно проверить их. Однако, если вы создали их из-за необходимости разработки через TDD, вы обнаружите, что после запуска инструмента покрытия кода эти POJO (или POCO для нас .net peeps) будут фактически покрыты. Это связано с тем, что TDD позволит вам только писать / реорганизовывать код, управляемый некоторым модульным тестом.

Это то, что делает TDD лучше, чем модульное тестирование, ИМХО.

1 голос
/ 18 сентября 2008

Обычно POJO тестируются в некотором контексте. Если вы хотите выполнить некоторую логику, ЭТО должно быть проверено должным образом (в идеале, перед запуском этой логической реализации). Что касается добытчиков и сеттеров; проверять их, как правило, не нужно, поскольку покрытие получается путем проверки логики :-) Попробуйте проверить некоторые инструменты отчетности о покрытии, такие как Cobertura, Clover или попробуйте Emma, ​​и посмотрите, что нужно проверить. Мне очень нравятся отчеты Clover, показывающие самые опасные угрозы в коде.

1 голос
/ 18 сентября 2008

Я делаю, за исключением геттеров и сеттеров. Вы должны провести черту где-нибудь.

0 голосов
/ 04 марта 2016

Это необходимо сделать даже для «простых» геттеров и сеттеров по следующим причинам:

  • покрытие кода - если вы используете инструмент cc, вам нужно увеличить покрытие
  • когда-нибудь в будущем кто-то может решить поместить некоторую логику в один из ваших методов получения или установки, и тогда ваши тесты, вероятно, не пройдут, позволяя разработчикам настроить тесты (повысить осведомленность)

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

0 голосов
/ 18 сентября 2008

Нет, я не тестирую POJO, потому что:

1.- Если POJO содержит бизнес-логику, я извлекаю ее из POJO и, конечно, проверяю. Но этот тест уже вышел из POJO.

2.- Если POJO не содержит его, то есть простые методы / getters / setters, я генерирую его динамически, во время сборки или во время выполнения ( CGLIB ). Поэтому я тестирую свой генератор кода, но не мои POJO.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...