Здравствуйте! У меня возникла ситуация, связанная с написанием тестов для <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 корректно и убедиться в надежности и стабильности вашего приложения.
<blockquote>Вся логика выборок, фильтров и т.д. вынесена на уровень Storage Procedure, значит не получится создать тестовую БД с тестовыми данными.<br/> </blockquote> <br/> Это ещё почему? Во время прогона тестов поднимаете полноценную СУБД, которую заполняете всеми табличками и процедурами. <br/> Больше вариантов нет, если хочется этот слой протестировать. <br/> При наличии миграций - это не должно быть сильно сложно. <br/> <br/> В крайнем случае можно взять дамп продовой базы, вычистив все чувствительные данные.
Мне не нравится сама идея <b>тестирования базы</b> . <br/> <br/> Тестируют обычно <b>бизнес логику</b> . Слой Services, Processors e.t.c. <br/> <br/> Если ваш язык программирования бизнес-логики это PL/SQL, T/SQL e.t.c. то я вам сочувствую. <br/> Наверное в этом и есть <b>главная причина ваших трудностей</b> . Эти языки <b>неудобно </b> тестировать <br/> и практики тестирования наподобие *Unit, *Property e.t.c. тестов там исторически не прижились. <br/> <br/> Создание тестовой БД в таком случае - да. Это компромисс. Вот и двигайте в этом направлении. <br/> Поднимайте все в контейнере типа docker.
Решение простое - создаешь мок БД для тестов. <br/> 1. Тест начинается - запускаешь БД и заполняешь данными необходимыми (как сказал <a href="https://qna.habr.com/user/vabka" rel="nofollow">Василий Банников</a> можно сделать дамп с удаленными чувствительными данными) <br/> 2. После каждого теста необходимо выполнить откат - если какие-то данные были добавлены/удалены/изменены <br/> 3. При завершении тестирования удаляешь БД <br/> <br/> На мой взгляд, здесь просто много инфраструктурной работы. Полезные инструменты: <br/> <br/> <br/> Также никто не отменял внешний инстанс БД использовать - просишь дба создать отдельную БД специально для тестов, просто запускать теперь параллельно не получится