Подход к тестированию - DB, Junit

Question

Я хотел бы спросить вас о том, как вы набираете тесты, связанные с данными из базы данных. На мой взгляд, лучший способ - иметь разную схему БД с правильными данными только для модульного тестирования. В тестовом коде я могу загрузить объект на основе идентификатора.

Вторая возможность заключается в помещении данных в базу данных во время модульного теста. Мне это не нравится.

Что вы думаете. Как ты делаешь это?

Сердечные приветы Себастьян

Answer 1

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

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

Другим способом было бы использовать «живую» базу данных и выполнять тесты внутри транзакции и откатывать изменения в конце теста. Spring и Unitils поддерживают это. Это тоже хорошо работает, но при использовании этого подхода не всегда легко диагностировать неудавшийся тест.

Обратите внимание, что второй подход действительно не исключает первый, вы можете использовать пользовательский набор данных внутри транзакции. Также обратите внимание, что вы можете использовать базу данных, содержащую «справочные данные» (т. Е. Данные только для чтения, такие как страны и т. Д.), И загружать только «динамические данные», чтобы ускорить работу при первом подходе.

Лично я не понимаю, что не так с прежним подходом (за исключением, может быть, тестов немного медленнее), инструменты вроде DbUnit делают это довольно легко. И, как я уже сказал, я обнаружил, что тесты с использованием DbUnit легче диагностировать. Но более поздний подход определенно работает.

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

_{На самом деле, с помощью одной схемы на одного разработчика, безусловно best practice.}

Answer 2

Для модульных тестов, вы должны издеваться или окурок функциональность базы данных. Поскольку вы тестируете объект, который вызывает базу данных, а не базу данных, нет необходимости использовать реальную базу данных. EasyMock или JMock - это хорошие насмешливые библиотеки для изучения.

Answer 3

Три комментарии:

1. Юнит-тесты, как правило, мелкомасштабные, быстрые тесты, чтобы покрыть небольшой кусок кода. Тесты с использованием БД - это не модульные тесты (даже если вы можете запускать их, например, JUnit), а скорее тесты системы/интеграции. Оба они полезны для разных целей.

2. Даже если ваш графический объект большой, я не понимаю, почему вам нужно будет протестировать его все сразу в единичном тесте. Вы проверяете один DAO с необходимыми макетными объектами и утверждаете, что соответствующая часть графика объекта обрабатывается правильно. Затем напишите больше тестов для следующего DAO и т. Д.

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