Я подумывал создать новую, легкую базу данных базы данных. Я абсолютно ненавижу 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] в реальное значение null. Вы должны вручную добавить его. Скажите, кто не сделал это с dbunit? Каждый имеет. Это не должно быть так!
Это означает, что если у вас есть полиморфный объект, вы должны объявить все внешние ключи для таблиц объединения каждого подкласса в первой строке, даже если они равны нулю. Если вы делаете таблицу для всех шаблонов подклассов, вам все равно нужно указать все поля в первой строке. Это просто ужасно.
Что бы там ни было, чтобы удовлетворить меня, или я должен стать следующим разработчиком фреймворка с гораздо лучшей базой тестирования базы данных?
