Есть ли какие-то рекомендованные практики как правильно тестировать приложение, написанное с помощью linq2db? Примеры может какие-нибудь? Например, не совсем понятно, как сделать мок бд. Хотелось бы заменить таблицы просто массивами для тестирования или что-то в этом роде.

Здравствуйте, Аноним, Вы писали:

А>Есть ли какие-то рекомендованные практики как правильно тестировать приложение, написанное с помощью linq2db? Примеры может какие-нибудь? Например, не совсем понятно, как сделать мок бд. Хотелось бы заменить таблицы просто массивами для тестирования или что-то в этом роде.

Рекомендации такие же как и для любых других приложений, использующих любые другие библиотеки. Лично я предпочитаю использовать тестовые БД с тестовыми данными.

Здравствуйте, IT, Вы писали:

IT>Лично я предпочитаю использовать тестовые БД с тестовыми данными.

Присоединяюсь.
Вообще, для начала нужно решить, тестируем мы работу с БД или мокаем. Это вопрос для отдельной дискуссии/холивара.
Если тестируем, то лично я на своём опыте пришёл к выводу, что лучше тестовые данные заранее положить в тестовую БД (хранить что-то типа database_mini.sql + набор update-скриптов в репозитории), чем готовить в тесте, так получается проще. Если в тестовой БД чего-то чуть-чуть не хватает и нужно это только в одном тесте, то зачастую проще тогда это подготовить уже из теста (каждый тест выполняется в отдельной транзакции, которая в конце не коммитится), чем править дамп тестовой БД.

Здравствуйте, MozgC, Вы писали:

MC>Вообще, для начала нужно решить, тестируем мы работу с БД или мокаем. Это вопрос для отдельной дискуссии/холивара.
MC>Если тестируем, то лично я на своём опыте пришёл к выводу, что лучше тестовые данные заранее положить в тестовую БД (хранить что-то типа database_mini.sql + набор update-скриптов в репозитории), чем готовить в тесте, так получается проще. Если в тестовой БД чего-то чуть-чуть не хватает и нужно это только в одном тесте, то зачастую проще тогда это подготовить уже из теста (каждый тест выполняется в отдельной транзакции, которая в конце не коммитится), чем править дамп тестовой БД.

подниму не холивара ради.

Но такой тест является не модульным, а интеграционным. Вообще есть способы без паттерна repository мокнуть БД с linq2db?
Ну допустим я вытащил через некий MySuperDataContext сущности через IQueryable<T>, но как быть с Insert и Update? В простом варианте фиг бы с ним, а с Expression's? Добавлю, что вопрос не праздный, т.к. linq2db по сути сам призван заменить собою репозитарий и использоваться глубоко в бизнес-логике, и как мне тестировать в таком случае ее родимую (бизнес-логику) отдельно, а не весь стек включая sql и СУБД? В общем вопрос юнит-тестов с linq2db для меня открыт.

Здравствуйте, AK107, Вы писали:

AK>Но такой тест является не модульным, а интеграционным. Вообще есть способы без паттерна repository мокнуть БД с linq2db?
AK>Ну допустим я вытащил через некий MySuperDataContext сущности через IQueryable<T>, но как быть с Insert и Update? В простом варианте фиг бы с ним, а с Expression's? Добавлю, что вопрос не праздный, т.к. linq2db по сути сам призван заменить собою репозитарий и использоваться глубоко в бизнес-логике, и как мне тестировать в таком случае ее родимую (бизнес-логику) отдельно, а не весь стек включая sql и СУБД? В общем вопрос юнит-тестов с linq2db для меня открыт.

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

[Test]
public void Test()
{
  var repository = new Repository();
  repository.Customers = new List<Customer> { ... }; // тут на самом деле хелперы, чтобы много кода в тестах не писать и не дублировать
  
  var businessLogicProcessor = new BusinessLogicProcessor(repository);

  businessLogicProcessor.DoWhateverNeeded();

  // здесь проверяем результаты, которые либо возвратил предыдущий метод, либо BusinessLogicProcessor предоставляет их в виде свойств
  // а в рабочем коде, вместо проверки результатов, другой класс (работальщик с БД) взял бы результаты работы BusinessLogicProcessor'а и сохранил бы их в БД
}

Т.е. ключевой момент тут в том, что BusinessLogicProcessor не сохраняет сам результаты в БД, и не получает данные из БД напрямую (только через репозиторий, в котором данные легко подменить).

Добавлю. Тесты у нас работают на отдельной тестовой базе. Поэтому, в принципе, в тестах мы можем не подменять данные, и тогда репозиторий сам поднимет их из БД. Тут удобство в том, что много данных уже есть в тестовой базе, и можно их просто поднимать из базы, а не заполнять вручную в тестах. В реальности, в части тестов данные в репозитории не подменяются (и тогда он их сам грузит из БД), а в части тестов данные в репозитории подменяются, т.е. создаются такие данные, которые нужны для конкретного теста (когда таких данных нет в тестовой базе).