2009-07-30 2 views
0

В настоящее время мы тестируем классы сущностей и классы «рабочий», называя Java-сервлеты для каждого объекта и выполняем Вставку, обновление, удаление, поиск ... для каждого объекта, чтобы гарантировать, что он работает. Рабочие классы - это просто реализации интерфейса, который сохраняет объект в базе данных с помощью JDBC, они выполняют работу базы данных для сущности.Тестирование классов сущностей базы данных Java

Что мне интересно, каков наилучший способ проверки классов объектов на Java?

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

+0

Как вы просите об отличном от простого модульного тестирования? –

ответ

2

Вы должны иметь возможность настраивать и использовать сущности и классы «рабочий» (как вы выразились) самостоятельно или сервлеты и веб-контейнер.

С чистым JDBC и JUnit, вы, как правило, выполните следующие действия:

  1. Открыть соединение JDBC в TestCase конструктору.
  2. Начните сделку с setUp().
  3. Отменить операцию на tearDown().
  4. Используйте фактические экземпляры сущности в конкретных методах testXxx().

В этом подходе у вас будет один, возможно, локальный экземпляр базы данных для каждого разработчика. Для чего-то более продвинутого, рассмотрите DbUnit.

0

Одним из вариантов было бы использовать отражение, чтобы найти разные части сущностей (т. Е. Разные поля), а затем использовать метод save, update, delete и т. Д., Используя эти разные объекты. Затем, когда вы добавили новый объект, если ваша настройка выполняется с помощью xml или чего-то подобного, тест просто подберет их.

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

+0

Можете ли вы пояснить часть «использование отражения»? Как это поможет в определении того, какие значения для заполнения объектов? Тем более, что некоторые (большинство?) Из них могут иметь ограничения, выраженные на уровне приложений и/или базы данных. – ChssPly76

+0

Итак, в спящем режиме у нас есть аннотации к классам, которые помогают отслеживать эту информацию, например, @column (length = 50), чтобы уведомить нас о том, что самое длинное, что может быть VARCHAR, равно 50. У нас также есть некоторые стандарты, например не делайте странной проверки в базе данных (т. е. причудливые, нестандартные ограничения). Вы можете найти тип каждого поля, а затем использовать его для генерации значения. Если поле само по себе является сущностью, вы можете либо присоединить существующую из базы данных, либо создать новую (в зависимости от ситуации - то есть отношения «многие-к-одному» и «многие-ко-многим»). – aperkins

+0

. Я должен сказать, однако, что похоже, что вы тестируете Hibernate Validator так же (или, более того), как ваши DAO :-) – ChssPly76

Смежные вопросы