Как правильно тестировать базу данных в .NET?

Question

[Nik Faraday]

Здравствуйте!

Возникла немного непонятная ситуация. Нужно написать тесты, но не знаю, как правильно тестировать Data Storage Layer и Data Access Layer. Проблема заключается в том, что мы используем Storage Procedure, а в качестве ORM - Dapper. Вся логика выборок, фильтров и т.д. вынесена на уровень Storage Procedure, значит не получится создать тестовую БД с тестовыми данными.

Заменить всё на Memory Data Storage так же не очень удобно будет, т.к. нужно тестировать Data Access Layer, т.е. тот же Dapper и что он будет выносить из БД.

Как в таком случае быть и как его правильно тестировать?

Comments

[Сергей Соловьев]

1. В каждом проекте Data Storage Layer и Data Access Layer могут означать разные вещи.
2. Что такое Storage Procedure? Хранимая процедура?
3. Не понял, почему нельзя создать тестовую БД

[Nik Faraday]

Сергей Соловьев,
1. Data Storage Layer это уровень БД, уровень процедур, Data Access Layer - уровень Dapper
2. +
3. Потому что нужно очень много вещей переносить и очень много чего изменять в проекте, там микросервисы

[shurshur]

А почему не получится тестовую базу создать? Можно даже инициализировать её с помощью ORM, даже сделать из этого отдельные тесты, которые проверяют, что база создалась и в ней количество и состав данных соответствуют ожидаемому...

Answer 1

[Сергей Соловьев]

Решение простое - создаешь мок БД для тестов.
1. Тест начинается - запускаешь БД и заполняешь данными необходимыми (как сказал Василий Банников можно сделать дамп с удаленными чувствительными данными)
2. После каждого теста необходимо выполнить откат - если какие-то данные были добавлены/удалены/изменены
3. При завершении тестирования удаляешь БД

На мой взгляд, здесь просто много инфраструктурной работы. Полезные инструменты:

1. Testcontainers - запускаешь БД в контейнере. Сам ей пользовался, есть много шаблонов для разных БД, чтобы с нуля не писать все. Можно также скрипт инициализации (схема, дамп) добавить - вот тебе и настройка
   
2. В зависимости от фреймворка есть разные механизмы запуска кода после каждого тест-кейса. Если про xUnit, то:
   1. Тестовый класс реализует IDisposable - выполняется после каждого тест-кейса. Можно тут реализовать логику отката БД
      
   2. Для инициализации самого контейнера (чтобы каждый раз не запускать заново) - IClassFixture
   
   

Также никто не отменял внешний инстанс БД использовать - просишь дба создать отдельную БД специально для тестов, просто запускать теперь параллельно не получится

Answer 2

[mayton2019]

Мне не нравится сама идея тестирования базы.

Тестируют обычно бизнес логику. Слой Services, Processors e.t.c.

Если ваш язык программирования бизнес-логики это PL/SQL, T/SQL e.t.c. то я вам сочувствую.
Наверное в этом и есть главная причина ваших трудностей. Эти языки неудобно тестировать
и практики тестирования наподобие *Unit, *Property e.t.c. тестов там исторически не прижились.

Создание тестовой БД в таком случае - да. Это компромисс. Вот и двигайте в этом направлении.
Поднимайте все в контейнере типа docker.

Comments

[Nik Faraday]

Да, я бы поднял бы это всё в Docker'е, но не получается. Там микросервисы на Orleans, и что-то с неделю не могу понять, почему там 30_000 порт не связывается между ними. Тут вопрос больше, как перенести процедуры между Dev Db и Test Db если их очень много

[mayton2019]

Nik Faraday, спроси у специалистов по БД. Должен быть migration guide.

По поводу порта - ничего непонятно. Подними отдельным вопрсом.

[Nik Faraday]

mayton2019, поднимал, нигде никто ничего не знает. Знаю, что там вроде как без Kubernetes оно не хочет работать. Почему? Чёрт его знает, но пока это таска на другой план ушла

[mayton2019]

Какая БД. Oracle? MS-SQL?

[Nik Faraday]

mayton2019, postgres

[mayton2019]

Я читернул немного и спросил умный чат. Вот примерно такой план.

• Export Schema Definitions: Use PostgreSQL's pg_dump utility to export specific schema objects. This might include:
  
• Functions/Procedures: pg_dump -s -f functions.sql --schema= --table=functions
  
• Triggers: pg_dump -s -f triggers.sql --schema= --table=triggers
  
• Types and Operators: Similarly, extract these separately if needed.
  
• Export Data: If needed, export the data separately to ensure referential integrity during migration.
  

Для импорта соотв надо просто исполнить эти скрипты.

Answer 3

[Василий Банников]

Вся логика выборок, фильтров и т.д. вынесена на уровень Storage Procedure, значит не получится создать тестовую БД с тестовыми данными.

Это ещё почему? Во время прогона тестов поднимаете полноценную СУБД, которую заполняете всеми табличками и процедурами.
Больше вариантов нет, если хочется этот слой протестировать.
При наличии миграций - это не должно быть сильно сложно.

В крайнем случае можно взять дамп продовой базы, вычистив все чувствительные данные.

Comments

[Nik Faraday]

Миграций нет, т.к. используем Dapper. Процедур много, т.к. система достаточно большая. В любом случае, спасибо

[Василий Банников]

Nik Faraday,

Миграций нет, т.к. используем Dapper.

А каким образом даппер мешает написанию миграций?
Никто не запрещает писать миграции на каком-нибудь FluentMigrations, Liquibase или вообще сырые sql-файлы.

Answer 4

[Артур Нуруллин]

Тестировать бд не надо
Надо тестить общую логику.
Поднимаете контейнер с базой данных и тестируете.
База данных существует во время всей сессии тестов.
Потом контейнер убивается.

Comments

[Nik Faraday]

Спасибо. В том и проблема, как из Dev Db сделать Test Db есть там очень много процедур и логики на этом уровне, прям достаточно много

[Артур Нуруллин]

Так какая разница.
Можно копию обезличенную делать.
Либо просто копию вырезанную по определенным критериям.
Выход всегда найдется

[Nik Faraday]

Артур Нуруллин,

Выход всегда найдется

Это понятно, по этому и спрашиваю, как его найти)