Отражение в модульных тестах для проверки покрытия кода

Question

Вот сценарий. У меня есть объекты VO (Value Objects) или DTO, которые являются просто контейнерами для данных. Когда я возьму их и разделю на части для сохранения в БД, которая (по многим причинам) не соответствует элегантности виртуальных организаций, я хочу проверить, успешно ли каждое поле создается в базе данных и успешно ли считывается обратно восстановить ВО.

Есть ли способ проверить, охватывают ли мои тесты все поля в ВО? У меня была идея об использовании отражения для итерации по полям VO как части решения, но, может быть, вы, ребята, уже решили проблему раньше?

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

среда разработки: Использование JUnit, Hibernate / Spring и Eclipse

Answer 1

Не усложняйте : напишите один тест на VO / DTO:

1. заполнить VO / DTO данными испытаний
2. сохранить
3. (необязательно: проверьте, все ли правильно сохранено на уровне базы данных, используя чистый JDBC)
4. загрузить
5. проверить, совпадает ли загруженный VO / DTO и исходный

Продуктивный код будет развиваться, и тесты также необходимо будет поддерживать. ИМХО лучший подход - сделать тесты максимально простыми, даже если они повторяются. Чрезмерная инженерия тестов или сама структура тестирования для создания общих тестов (например, путем чтения полей с отражением и автоматического заполнения VO / DTO) приводит к нескольким проблемам:

1. время, потраченное на написание теста выше
2. Ошибка может быть введена в самом тесте
3. обслуживание теста сложнее, потому что они более сложные
4. тесты сложнее развиваться, например, универсальный код, возможно, не будет работать для новых видов VO / DTO, которые немного отличаются от других и будут представлены позже (это только пример)
5. тесты не могут быть легко использованы в качестве примера того, как работает производительный код

Тестовый и производительный код сильно различаются по природе . В продуктивном коде вы пытаетесь избежать дублирования и максимально использовать повторно. Продуктивный код может быть сложным, потому что он проверен. С другой стороны, вы должны постараться сделать тесты максимально простыми, и дублирование в порядке. Если дублирующаяся часть повреждена, проверка все равно не будет выполнена.

При изменении производительного кода для этого может потребоваться тривиальное изменение 1038 *. С проблемой в том, что тесты воспринимаются как скучный кусок кода. Но я думаю, что так и должно быть.

Если я, однако, неправильно понял ваш вопрос, просто дайте мне знать.

Answer 2

Я бы порекомендовал cobertura для этой задачи. После выполнения тестов вы получите полный отчет о покрытии кода, и если вы используете задачу cobertura-check ant, вы можете добавить проверки для покрытия и остановить вызов ant с помощью свойства haltonfailure.

Answer 3

Вы можете сделать это частью проверки VO. Если поля не установлены при использовании метода получения, он может выдать исключение.