it-swarm.com.ru

Существует ли подобный dbunit фреймворк, который не подходит для Java/scala?

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

Что мне не нравится в dbunit:

1) Самый простой формат для написания и начала работы устарел. Они хотят, чтобы вы использовали раздутые форматы. Некоторые даже требуют XML-схем. Да что угодно.

2) Они заполняют строки не в том порядке, в котором вы их пишете, а в таблицах порядка, определенных в файле XML. Это действительно плохо, потому что вы не можете упорядочить данные таким образом, чтобы ограничения внешнего ключа не вызывали проблем. Это просто заставляет вас проходить через все трудности их полного отключения. 

Это также напрасно тратит время и увеличивает ваши базовые классы junit для включения кода для отключения ограничений внешнего ключа. Вам, вероятно, придется проверить тип базы данных (hsqldb и т.д.) И отключить их в зависимости от базы данных. Это очень плохо.

Было бы лучше, если бы dbunit автоматически отключил ограничения внешнего ключа как часть их инфраструктуры, но они этого не делают. Они следят за диалектами ... так почему бы не использовать их для этого? В конечном итоге все это заставляет программиста тратить время, а не быстро вставать и тестировать.

3) XML - это боль для написания. Мне не нужно больше говорить об этом. Они также предлагают так много способов сделать это, что я думаю, что это только усложняет ситуацию. Просто предложите один действительно надежный способ и покончите с этим.

4) Когда ваши данные становятся большими, отслеживание идентификаторов и их последовательных/правильных отношений является королевской болью. 

Кроме того, если вы не работали над проектом в течение месяца, как вы помните, что user_id 1 был администратором, user_id 2 был бизнес-пользователем, user_id 3 был инженером, а user_id 4 был чем-то другим? Возвращаясь, чтобы проверить, что это напрасная трата времени. Там должен быть осмысленный способ получить его, кроме произвольного числа.

5) Это медленно. Я обнаружил, что если не использовать hsqldb, он мучительно медленный. Это не должно быть. Есть также множество способов испортить его конфигурацию, так как это не так просто сделать «из коробки». Есть горб, через который вы должны пройти, чтобы заставить его работать правильно. Все, что это делает, - это побуждает людей не использовать его, или раздражаться, когда он начинает его использовать.

6) Некоторые значения часто повторяются, любит даты. Было бы неплохо указать значения по умолчанию или даже сделать так, чтобы фреймворк автоматически вводил значения по умолчанию, даже если вы не сказали, чтобы они вводили значения по умолчанию. Таким образом, вы можете создавать объекты только с теми значениями, которые вам нужны, а оставшиеся отключены. Это наверняка лучше, чем указывать каждый закоулок колонны, если это не требуется.

7) Вероятно, самая раздражающая вещь состоит в том, что первая запись должна включать ВСЕ значения - даже нулевые заполнители - или будущие строки не будут выбирать столбцы, которые вы фактически указали.

DBunit также не имеет разумного значения по умолчанию для перевода [NULL] в реальное нулевое значение. Вы должны вручную добавить его. Скажите, кто не делал этого с dbunit? Каждый имеет. Так не должно быть!

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

Есть что-нибудь, что меня удовлетворит, или я должен стать следующим разработчиком фреймворка для гораздо лучшей среды тестирования баз данных?

59
egervari

Я не знаю никакой реальной альтернативы DbUnit, и ни один из инструментов, упомянутых @Joe , не находится в моих глазах:

  • Incanto : не зависит от БД
  • SQLUnit : регрессионное и модульное тестирование для тестирования хранимых процедур в базе данных (это не то, чем занимается DbUnit)
  • Cactus : инструмент для тестирования в контейнере (я не вижу, где он помогает с базами данных)
  • Liquibase : инструмент миграции базы данных (не загружает/не проверяет данные)
  • ORMUnit : может инициализировать базу данных, но это все
  • JMock : вообще не конкурирует с DbUnit

При этом я лично несколько раз успешно использовал DbUnit в небольших и огромных проектах, и я нахожу его довольно удобным, особенно при использовании Unitils и его модуля DbUnit. Это не значит, что он идеален и не может быть улучшен, но с приличным инструментарием (либо сделанным на заказ, либо чем-то вроде Unitils) его использование было достойным опытом.

Итак, позвольте мне ответить на некоторые ваши вопросы:

1) Самый простой формат для написания и начала работы устарел. Они хотят, чтобы вы использовали раздутые форматы. Некоторые даже требуют XML-схем. Да что угодно.

DbUnit поддерживает плоский или структурированный XML, XLS, CSV. Какой революционный формат вы бы хотели использовать? Кстати, DTD или схема не обязательны при использовании XML. Но это дает вам хорошие вещи, такие как проверка и автозаполнение, как это плохо? И Unitils может легко сгенерировать его, см. Генерация XSD или DTD структуры базы данных .

Было бы лучше, если бы dbunit автоматически отключил ограничения внешнего ключа как часть их инфраструктуры, но они этого не делают. Они следят за диалектами ... так почему бы не использовать их для этого? В конечном итоге все это заставляет программиста тратить время, а не быстро вставать и тестировать.

Они ждут вашего патча. 

Между тем, Unitils обеспечивает поддержку для прозрачной обработки ограничений, см. Отключение ограничений и обновление последовательностей

3) XML - это боль для написания. Мне не нужно больше говорить об этом. Они также предлагают так много способов сделать это, что я думаю, что это только усложняет ситуацию. Просто предложите один действительно надежный способ и покончите с этим.

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

4) Когда ваши данные становятся большими, отслеживание идентификаторов и их последовательных/правильных отношений является королевской болью. 

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

Кроме того, если вы не работали над проектом в течение месяца, как вы помните, что user_id 1 был администратором, user_id 2 был бизнес-пользователем, user_id 3 был инженером, а user_id 4 был чем-то другим? Возвращаясь, чтобы проверить, что это напрасная трата времени. Там должен быть осмысленный способ получить его, кроме произвольного числа.

Да, переключение задач контрпродуктивно. Но поскольку вы работаете с низкоуровневыми данными, вы должны знать, как они представлены, и волшебного решения не будет, если вы, конечно, не используете API более высокого уровня (но это не цель DbUnit).

5) Это медленно. Я обнаружил, что если не использовать hsqldb, он мучительно медленный. Это не должно быть. Есть также множество способов испортить его конфигурацию, так как это не так просто сделать «из коробки». Есть горб, через который вы должны пройти, чтобы заставить его работать правильно. Все, что это делает, - это побуждает людей не использовать его, или раздражаться, когда он начинает его использовать.

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

6) Вероятно, самая раздражающая вещь состоит в том, что первая запись должна включать ВСЕ значения - даже нулевые заполнители - или будущие строки не будут выбирать столбцы, которые вы фактически указали.

Не при использовании Unitils, как упоминалось в презентациях, таких как Unitils - Home - JavaPolis 2008 или Модульное тестирование: unitils & dbmaintain

Есть что-нибудь, что меня удовлетворит, или я должен стать следующим разработчиком фреймворка для гораздо лучшей среды тестирования баз данных?

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

96
Pascal Thivent

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

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

Я подробно расскажу scaladbtest в надежде, что мы сможем объединить их идеи.

26
Roberto Lo Giacco

Столкнувшись с аналогичными проблемами при использовании DBUnit, я нашел это: http://dbsetup.ninja-squad.com/index.html , который может решить проблемы. Например, вместо представления тестовых данных в отдельных файлах весь контент БД содержится в самом классе Java.

16
blue-sky

Если вы используете Spring Framework (или не возражаете использовать его хотя бы для тестирования), то Spring DBUnit в настоящее время является лучшей (поддерживаемой) альтернативой обычному DBUnit, который я знаю и использую. Цитирую их сайт:

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

Spring DBUnit представляется «несколько официальным» решением Spring для модульного тестирования БД (с DBUnit); по крайней мере, автор/сопровождающий библиотеки Фил Уэбб работает в SpringSource/Pivotal.

4
Chriki

Я использую DBUnit с несколькими обертками, чтобы сгладить неровные края. Хорошим инструментом, который может дополнять или перекрывать функциональность, является Jailer . Он может извлекать подмножества данных из справочной базы данных и сохранять их либо как XML-файлы, совместимые с DBUnit, либо как «топологически отсортированные файлы DML», которые соответствуют ограничениям внешнего ключа.

3
retronym

Вы делаете отличное замечание. 

В последние годы я работал на многих веб-порталах, в основном с PHP, но также и с некоторыми Java.
И, как и вы, я не понимаю, что после всех этих лет разработчики фреймворков и юнит-тестов, похоже, не понимают, насколько сильно изменилась обработка хранилищ за последнее десятилетие . Недостаточно просто отправить команду create/insert/усекать операторы в какую-либо базу данных! Плюс на фронте базы данных есть проблема разделения данных. Если у вас нет подходящей абстракции внешнего ключа, вы наверняка сойдете с ума, когда ваши настройки хранилища изменятся. И пока мы на этом: упорядочение приборов по приоритету внешнего ключа имеет много подводных камней, и мне еще предстоит найти реальное решение для этого с DBUnit

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

Не желая походить на фаната: единственное место, где все в порядке, это Ruby on Rails. У этого есть постоянная модель, которую люди, кажется, действительно думают. Если вы имеете дело с PHP, Symfony - это то, что вам нужно. Он ограничен включением по умолчанию Doctrine, причем он также довольно ориентирован на DB, но он имеет чистые интерфейсы и большую расширяемость и полностью скопировал систему фиксации Rails. В профессиональном плане мне сейчас нужно придерживаться доморощенных решений, но они работают хорошо.

2
carrion

Я только что выпустил библиотеку под названием JDBDT (Дельта-тестирование базы данных Java), которую вы можете использовать для настройки и проверки базы данных в тестах программного обеспечения.

Посмотрите на http://jdbdt.org

Лучшее, Эдуардо

2
edrdo

Вот краткий список нескольких инструментов в этом ключе (кроме DBunit), которые мне особенно нравятся или которые мне интересны. По крайней мере, они могут предложить некоторое вдохновение:

Обратите внимание, что ни один из них на самом деле не является конкурентом DBunit с точки зрения области действия или набора функций. Тем не менее, есть некоторые интересные идеи, на которые стоит обратить внимание. Удачи!

1
Joseph Weissman

Мы пишем Daleq как обертку вокруг DbUnit для решения некоторых из упомянутых проблем. Это позволяет заполнять БД только внутри вашего модульного теста, а не полагаться на редактирование файлов XML. 

1
Lars

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

Это вдохновило меня на написание новой библиотеки: https://github.com/jeffskj/phonydata

При этом используется базовый DSL для определения наборов данных, который обеспечивает очень компактное представление данных и позволяет выполнять интересные вещи, такие как генерация случайных данных, поскольку это просто отличный код.

1
Jeff S

Ситуация с DBUnit действительно иногда расстраивает. Некоторые проблемы решаются из Marc Philipp with dbunit-datasetbuilder , особенно если вы объедините его с validator , который находится на очень ранней стадии. Вы можете увидеть это в действии на SZE .

Отказ от ответственности: все упомянутые github-ресурсы поддерживаются мной.

0
niels

Я только что выпустил отличный фреймворк на основе DSL под названием pedal-loader, доступный через github . Документация здесь .

Это позволяет вам напрямую работать с абстракцией уровня сущности JPA. Так как это скрипт Groovy, вы можете использовать все конструкции Groovy. 

Чтобы вставить строки в таблицу, поддерживаемую сущностью JPA с именем Student, с полями (не столбцы базы данных, а сопоставленные поля) с именами id, name и grade, вы должны сделать что-то вроде этого:

allStudents = table(Student, ['id', 'name', 'grade']) {
    row 1, 'Joe', Grade.A
    rowOfInterest = row 2, 'John', Grade.B
}

Оценка - это перечисление в классе Student, которое сопоставляется со столбцом базы данных (возможно, с использованием аннотации JPA 2.1 @Convert). allStudents - это список, в котором будут храниться строки, а rowOfInterest - это ссылка на конкретную строку. Эти свойства (allStudents и rowOfInterest) становятся доступными для вашего модульного теста.

0
Καrτhικ

Альтернативу использованию конфигурации Spring и Specs2 можно найти здесь

0
pagoda_5b