Как заставить DbContext использовать работу оператора с модульными тестами?
===========================================================================

 Ситуация у меня такова: 

1. Я работаю над проектом ASP.NET MVC, который не реализует шаблон репозитория
2. Все вызовы `DbContext` выполняются из уровня контроллера
3. `DbContext` в оператор using и создается в случае необходимости для целей управления памятью.
4. Нам нужно провести тестирование этих контроллеров, что означает введение `DbContext` в контроллер.
5. Мы не используем контейнер IoC. Я должен был бы создать новый экземпляр в конструкторе без параметров и использовать его для жизни вызова контроллера.
6. Я не могу изменить большинство этих условий.

 Условия, которые я могу изменить: 

1. Избавьтесь от инструкции using, если надежный вариант может занять ее место.
2. Признайте, что этот код просто не проверяется как есть, и переходите к расходу энергии в другом месте.

 Итак, мой вопрос заключается в следующем: как передать в конструктор `DbContext` чтобы я мог издеваться над возвращаемыми ответами, но сохраняю надежность инструкции using, поскольку они имеют тенденцию противоречить друг другу. 

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

 Любые мысли об этом? 

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

* Внедрите поставщика данных в памяти, чтобы указать EF для модульных тестов.
* Настройте базу данных известного состояния, которая может быть восстановлена между тестовыми запусками. (Больше интеграционного теста, не очень подходящего для TDD, где вам нужны тесты, которые могут работать очень быстро, очень часто).
* Поместите его в ведро «не предназначено для модульного тестирования» из-за отсутствия DI / IoC

 Издевательство над DbContext бесполезно, но делает. Если у вас есть один макет, я бы рекомендовал добавить в проект контейнер IoC, такой как Autofac. Я не знаю обстоятельств, которые мешали бы вам вводить контейнер IoC, но если команда беспокоится о том, что он является ревакцином «все или ничего» и слишком большой работой, я бы успокоил их, что это могут быть добавлены с минимальными изменениями в проекте и таким образом, чтобы не нарушать существующий код. Помимо DbContext, если код не использует DI / IoC Container, как вы планируете обрабатывать другие конкретные зависимости? Вам не нужно отключать *все* зависимости / контроллеры за один раз, но улучшать их постепенно. 

 Как только контейнер настроен для разрешения контроллеров MVC, существующие контроллеры со стандартными конструкторами не будут затронуты. Затем вы можете зарегистрировать свой DbContext с контейнером и настроить тестовый контроллер, чтобы принять контекст в конструкторе. Контейнер IoC настроил бы область действия DbContext на экземпляр для запроса, например, вам не нужен блок `using {}` . Оттуда ваши тесты могут обеспечить насмешливый DbContext, в то время как контейнер управляет продолжительностью Context. 

 Что касается создания дружественных контроллеров / кода unit-test с контейнером IoC, я недавно опубликовал статью об использовании зависимостей Lazy / w Autofac, чтобы сделать тесты записи для классов с несколькими зависимостями. Вы можете прочитать на <https://medium.com/@StevePy/writing-easily-testable-code-with-autofac-lazy-properties-f9c63457c8ce>