Автоматизированного тестирования классов домена (не модульное тестирование)

Question

Текущего Выпуск

Пожалуйста, обратитесь к соответствующему сообщению: What can go wrong in hibernate domain classes – so that we need to (unit) test them? В моем новом проекте J2EE, я пытаюсь проверить (не обязательно модульные тесты) объекты предметной области Я начинаю писать. Они не вовлекают большую часть бизнес-логики (бизнес-логика является частью бизнес-службы поверх объектов DAO), и, тестируя, я по сути обеспечиваю целостность объектов домена, и я пытаюсь это сделать, тестируя DAO методы. Обратите внимание: я не могу протестировать объекты домена с помощью JUnit и т. Д., Поскольку у них нет никаких методов в моем случае, и у них есть атрибуты и аннотации отображения гибернации.

Например, Пациент объект домена. PatientDAO имеет дело с операциями CRUD объекта домена пациента. Вот методы (не полные и намеревающиеся добавить еще немного для проверки граничных условий).

Примечание: Я не называю это модулем тестов, они могут быть мини-интеграционными тестами и т. Д. Я в порядке, этот подход работает при тестировании объектов домена.

PatientDAOTest класс содержит: - testCreatePatient(); - testUpdatePatient(); - testFindPatient(); - testDeletePatient();

PatientDAO класс содержит: - createPatient(); - updatePatient(); - findPatient(); - deletePatient();

Позволяет нам рассмотреть метод testUpdatePatient(), который проверяет метод updateMethod() в объекте домена. Теперь, как я буду внедрять метод testUpdatePatient()? Ну, я думаю: 1. Получите существующего пациента с использованием метода домена «findPatient()» 2. Обновите запись пациента с новыми данными. 3. Сохраните его обратно в базе данных с помощью метода domainPatient() 4. Получение записи пациента обратно из базы данных, используя «findPatient()» метод домена 5. Assert для обновленных данных

Вопрос

Как вы можете видеть, я использую базу данных в тестирование, с которым я в порядке, но есть ли какие-либо проблемы с этим подходом?

Каков мой реальный вопрос (прочитайте как вопрос) об этом подходе?

мне нужно использовать 'findPatient()' метод (фактически в 2 раза) при тестировании 'updatePatient()'. Это то, что мне не нравится, тот факт, что я должен использовать другой метод при тестировании метода, в то время как другой метод сам по себе может быть ошибкой. Эта же история повторяется, когда я пытаюсь проверить другие методы CRUD.

В качестве альтернативы, я мог бы написать select sql query для извлечения записи пациента из базы данных для утверждения (после запуска обновления) из тестового метода, но он просто побеждает цели использования hibernate (чтобы уменьшить усилия SQL-кодирования), следовательно, мне не нравится этот подход.

Мой вопрос в том, что обстоит дело с другими методами для проверки конкретных методов и это не плохой подход? Если это не так, как я должен проверять отображение ORM в объектах моего домена.

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

Answer 1

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

1. Это совершенно нормально, чтобы включить использовать тест insede функция (findPatient) другого признака (updatePatient), но только если у вас есть еще один тест, который покрывает сам в одиночку findPatient.
2. Для методической части тестирования интеграции с БД вы можете рассмотреть возможность использования выделенной автоматической тестовой БД, очистить все данные и перенести их в желаемое состояние как setUp вашего модульного теста. Выполните инициализацию своей базы данных с помощью выборочных исходных данных с использованием чистых SQL-скриптов (TRUNCATE TABLE Patients, INSERT INTO Patients ...) - то, что я использовал, - это переключение между несколькими состояниями исходных данных имени DB (например, «cleanDB», «twoPatientsSimple1», «twoPatientsLenkedToInsuranceContracts1 " и т.д.). Дело здесь в том, что ваша БД изменяется во время модульных тестов и использует чистый ROLLBACK для входа в состояние до того, как тест не гарантирует точное состояние, которое вы хотите (например, вы можете явно зафиксировать во время теста, а ваши данные попадут в другое, чем начальное состояние). Вы также можете включить тесты для обеспечения состояния БД после того, как тест изменит его, снова с помощью чистого SQL. Тестирование с использованием этого подхода, как правило, выполняется медленно и сложнее в обслуживании (если у вас нет набора собственных вспомогательных инструментов), но он дает вам полную уверенность в ваших данных и поведении. После того, как вы это сделаете, это значительно сэкономит вам время и путаницу во время пользовательского интерфейса/функционального тестирования. Это может сойти ужасно, но когда вы немного играете с ним, вы получаете простые наборы данных состояния БД (например, представленные как TSVs/CSV внутри ваших тестовых случаев) «initState» и «expectedState», и вы просто используете эти состояния для инициализации/сравнения до/после тестируемого поведения.
3. Для истинного модульного тестирования объектов домена (не интегрированного с БД) вы должны издеваться над вашими классами DAO/Repository/DataMapper, например. с простыми обобщающими списками (createPatient добавляет его в список и т. д.)
4. Для тестирования интеграции самого ORM (вашего, третьего лица или вашего расширения одного) вы должны использовать метод в пункте 2 с некоторыми примерными данными (не обязательно ваши объекты домена) достаточно сложны, чтобы дать вам уверенность в том, как работает ваш ORM. Например. Microsoft Entity Framework работала очень непредсказуемо на ранних этапах, поэтому для написания полного интеграционного теста функций, которые вы обычно используете, можно избежать отладки ошибок и проблем с самой ORM и показывает, как именно ORM ведет себя в разных условиях.