Различия между базой данных / структурой сущностей и списками памяти при моделировании в модульных тестах

Question

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

Некоторые из этих ситуаций могут быть:

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

2. Операторы Linq, которые могут передаваться в коллекцию в памяти, но не будут работать в платформе сущностей, поскольку они не поддерживаются, что приводит к ложному проходу.

Как правильно обрабатывать или учитывать эти различия, чтобы в тестах не было ложных прохождений или неудач?Мне действительно нравится издеваться, потому что это делает вещи намного быстрее и проще для тестирования.Но мне кажется, что единственный способ получить действительно точный тест состоит в том, чтобы просто протестировать среду среды / базы данных сущностей.

Answer 1

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

Я не эксперт по EF, но с NHibernate, например, вы можете создатьконфигурация, которая указывает на экземпляр SQLite в памяти, в котором вы затем запускаете свои быстрые тесты (то есть во время цикла разработки, когда вы хотите пройти набор тестов как можно быстрее).Когда вы хотите запустить свои интеграционные тесты для реальной базы данных, вы просто изменяете конфигурацию NHibernate, чтобы она указала на реальную настройку базы данных, и снова запускаете те же тесты.

Было бы удивительно, если бы вы не смогли добиться чего-то подобного с EF.

Answer 2

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

Answer 3

Первое и самое важное, что вы можете определить любые данные о поведении в вашем макете.Второе - это скорость.С точки зрения модульного тестирования скорость тестирования имеет значение.Соединения с базой данных в большинстве случаев являются узким местом, поэтому вы издеваетесь над тестами.Чтобы правильно выполнить тестирование, вам сначала нужно поработать над своей общей аркой.Например, для доступа к слою данных я иногда использую шаблон хранилища.Это действительно хорошо описано в книге DDD Эрика Эванса.Скажем так, если ваш репозиторий определен как приведенный ниже интерфейс IRepository : IQueryable, ICollection, вы можете обрабатывать запросы linq довольно просто.Дальнейшее чтение Репозиторий

Answer 4

Вы можете использовать DevMagicFake , этот фреймворк подделает БД для вас, а также может генерировать данные, чтобы вы могли протестировать свое приложение без тестирования БД