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

Question

Это необходимо?

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

Конечно, что еще вы будете делать в тестовых случаях?

Мне нравится делать Test Driven Development, и это очень полезно для тестирования ваших pojos (ну, на самом деле, о проектировании ваших pojos).

Answer 5

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

С яркой стороны их намного легче проверить.

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

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

Answer 11

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

Answer 12

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

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

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

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

Answer 13

Нет, я не испытываю POJOs, потому что:

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

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

Answer 14

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

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

Answer 15

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

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

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

Answer 16

Вам нужно сделать, что даже для «простых» получения и установки по этим причинам: охват

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

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