Здравствуйте! У меня возникла ситуация, связанная с написанием тестов для <code>Data Storage Layer</code> и <code>Data Access Layer</code>, используя <code>Storage Procedure</code> и <code>Dapper</code>. Наша проблема заключается в том, что всю логику запросов, фильтрации и т.д. мы реализовали через <code>Storage Procedure</code>, что делает создание тестовой базы данных с тестовыми данными невозможным. Замена всего на <code>Memory Data Storage</code> также не лучший вариант, так как нам нужно протестировать <code>Data Access Layer</code> и проверить работу <code>Dapper</code>. Как можно решить эту проблему и как корректно протестировать это?
Для проведения тестирования баз данных в .NET правильно, вам следует рассмотреть следующие рекомендации: 1. Используйте интеграционные тесты для проверки работы Data Access Layer с реальной базой данных. Создайте тестовую базу данных, наполните ее тестовыми данными и выполните запросы к ней с помощью Dapper. 2. Для более удобного управления тестовыми данными и состоянием базы данных, вы можете использовать инструменты для создания и очистки тестовой базы данных перед и после выполнения тестов, например, библиотеку <code>DBUnit</code> или аналогичные. 3. Если использование хранимых процедур создает проблемы при создании тестовых данных, вы можете рассмотреть возможность замены хранимых процедур на SQL-запросы в коде. Это позволит вам более гибко управлять тестовыми данными и исключить зависимость от хранимых процедур при проведении тестирования. 4. Для тестирования сложных запросов и фильтрации данных вы можете использовать фреймворк для тестирования SQL-запросов, например, <code>SqlBulkCopy</code>, для проверки корректности работы запросов и обработки данных. 5. Не забывайте также о проведении модульных тестов для отдельных методов и функций Data Access Layer, чтобы удостовериться в их корректной работе. Соблюдая данные рекомендации, вы сможете провести тестирование баз данных в .NET корректно и убедиться в надежности и стабильности вашего приложения.
Вся логика выборок, фильтров и т.д. вынесена на уровень Storage Procedure, значит не получится создать тестовую БД с тестовыми данными.
Это ещё почему? Во время прогона тестов поднимаете полноценную СУБД, которую заполняете всеми табличками и процедурами.
Больше вариантов нет, если хочется этот слой протестировать.
При наличии миграций - это не должно быть сильно сложно.
В крайнем случае можно взять дамп продовой базы, вычистив все чувствительные данные.
Мне не нравится сама идея тестирования базы .
Тестируют обычно бизнес логику . Слой Services, Processors e.t.c.
Если ваш язык программирования бизнес-логики это PL/SQL, T/SQL e.t.c. то я вам сочувствую.
Наверное в этом и есть главная причина ваших трудностей . Эти языки неудобно тестировать
и практики тестирования наподобие *Unit, *Property e.t.c. тестов там исторически не прижились.
Создание тестовой БД в таком случае - да. Это компромисс. Вот и двигайте в этом направлении.
Поднимайте все в контейнере типа docker.
Решение простое - создаешь мок БД для тестов.
1. Тест начинается - запускаешь БД и заполняешь данными необходимыми (как сказал Василий Банников можно сделать дамп с удаленными чувствительными данными)
2. После каждого теста необходимо выполнить откат - если какие-то данные были добавлены/удалены/изменены
3. При завершении тестирования удаляешь БД
На мой взгляд, здесь просто много инфраструктурной работы. Полезные инструменты:
Также никто не отменял внешний инстанс БД использовать - просишь дба создать отдельную БД специально для тестов, просто запускать теперь параллельно не получится