Кто-нибудь делает тестовые примеры для pojos?

Pojos все еще может содержать логические ошибки.

Если он не был протестирован, значит, в нем есть ошибка! ;)

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

Конечно, на чем еще вы бы сделали тестовые примеры?

Мне нравится делать Разработка через тестирование, и он во многом связан с тестированием ваших pojos (ну, на самом деле, речь идет о разработке ваших pojos).

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

С другой стороны, их намного проще протестировать.

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

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

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

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

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

Конечно, если они содержат «критически важный» код, вы захотите их протестировать.

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

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

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

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

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

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

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

Итак, если вопрос был: «Следует ли мне тестировать свои POJO (содержащие бизнес-логику)?» ответ категорически да.

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

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

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

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

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

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

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

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

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

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

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

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