генерирование данных модульного теста для сложной БД (EAV)

Question

Я работаю с унаследованным приложением, которое использует известную / страшную модель моделирования данных, известную как EAV. Это затрудняло выбор стратегии генерации данных для использования во время модульного тестирования DAL. Зачем? Потому что, в дополнение к обычным ограничениям Fk / Pk между таблицами (которые мы используем, когда это возможно), существуют дополнительные отношения / ограничения, которые знает и применяет только прикладной уровень.

В соответствии с этой статьей самые простые тесты данных для записи и обслуживания - это те, которые основаны на внешне определенном и статическом наборе данных. Однако, похоже, что попытка создать набор данных, который включает отношения, уже смоделированные в моем прикладном слое «вручную», будет СУХОЙ нарушением и основной загрузки PITA. С другой стороны, использование моего прикладного уровня для генерации тестовых данных кажется еще более неприятным, поскольку это нарушает основную директиву модульного тестирования (изоляцию), поскольку регрессия на прикладном уровне может привести к тому, что мой уровень DAL вызовет фиктивные сбои.

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

Большое спасибо.

Answer 1

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

Вполне возможно, что "унаследованная" природа приложения затрудняет, если не невозможно, модульное тестирование уровней приложения и DAL по отдельности. По сути, два слоя в совокупности были бы одной (если сложной) "единицей". В этом случае было бы приемлемо (или, возможно, «допустимым» является правильным словом) генерировать тестовые данные с использованием прикладного уровня в целях целесообразности. Такое поколение, по сути, стало бы еще большим количеством контрольных примеров для "единицы" конгломерата. Отказы DAL из-за регрессий прикладного уровня следует исследовать как возможные ошибки на одном, другом или обоих уровнях. Любое время, потраченное на попытки разделить эти два слоя на отдельные единицы, в долгосрочной перспективе, вероятно, принесет дивиденды.