Есть ли dbunit -подобный фреймворк, который не подходит для java / scala?

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

Что мне не нравится в 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] в действительное значение NULL. Вы должны добавить его вручную. Подскажите, а кто с dbunit этого не делал? Каждый имеет. Так не должно быть!

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

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