Тестирование приложений EF Core

Тестирование имеет большое значение для почти всех типов приложений. Оно позволяет убедиться, что приложение работает правильно, и мгновенно выявляет, если его поведение регрессирует в будущем. Так как тестирование может повлиять на архитектуру кода, настоятельно рекомендуется планировать тестирование на ранних этапах и обеспечить хорошее покрытие по мере развития приложения. В этом вводном разделе представлен краткий обзор различных стратегий тестирования для приложений с помощью EF Core.

Включение базы данных (или нет)

При написании тестов для приложения EF Core необходимо принять одно базовое решение о том, будут ли тесты включать в себя рабочую систему базы данных - так же, как и ваше приложение, или будет ли тест выполняться с двойным тестом, который заменяет рабочую систему базы данных. Два известных примера тестовых двойников в контексте EF Core — это SQLite в памяти и поставщик на основе памяти.

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

• Разработчики часто избегают тестирования в рабочей базе данных, так как считают, что это сложно или медленно. Согласно нашему опыту, это не всегда так, и мы предлагаем использовать этот подход: тестирование на вашей производственной базе данных обеспечивает методы для этого надежно и эффективно. Написание по крайней мере некоторых тестов в базе данных обычно требуется в любом случае , чтобы убедиться, что приложение фактически работает с рабочей базой данных, и тесты, не связанные с базой данных, могут быть ограничены тем, что позволяет тестировать (см. ниже).
• Поставщик в памяти не будет вести себя так, как ваша реальная база данных во многих важных способах. Некоторые функции не могут быть протестированы с ним вообще (например, транзакции, необработанные SQL-запросы…), а другие функции могут вести себя не так, как продуктивная база данных (например, регистрозависимость в запросах). Хотя использование технологии in-memory может быть подходящим для простых и ограниченных сценариев запросов, эта технология имеет значительные ограничения, и мы не рекомендуем его использовать.
  • DbSet Мокирование запросов является сложным и страдает от тех же недостатков, что и подход с использованием памяти; мы это тоже не рекомендуем.
• Режим sqLite в памяти обеспечивает лучшую совместимость с рабочими реляционными базами данных, так как SQLite является полнофункциональной реляционной базой данных. Однако существуют некоторые важные несоответствия между SQLite и вашей рабочей базой данных, и некоторые функции не могут быть проверены вообще (например, методы, относящиеся к поставщику в EF.Functions).
• Для подхода к тестированию, который позволяет использовать надежный тестовый двойник для функциональности вашей продуктивной базы данных, можно внедрить уровень репозитория в приложение. Это позволяет полностью исключить EF Core из тестирования и полностью макетировать репозиторий; однако это изменяет архитектуру приложения таким образом, что может быть значительным, и включает в себя дополнительные затраты на реализацию и обслуживание.

Дополнительные материалы

Дополнительные сведения см. в разделе "Выбор стратегии тестирования". Рекомендации по реализации и примеры кода см. в статье "Тестирование для рабочей базы данных " и "Тестирование без рабочей системы базы данных".