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

Question

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

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

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

С уважением Себастьян

Answer 1

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

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

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

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

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

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

_{¹ На самом деле, использование одной схемы на разработчика определенно является лучшей практикой .}

Answer 2

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

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

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

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

Answer 3

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