Как писать unit тесты для DAL?

#c_sharp #юнит_тесты

К примеру есть классы с такими extension методами:

IQueryable ToViewDto(this IQueryable query)


Или элементарный Linq запрос (в другом классе):

_repository.Query
                .Where(x => x.Id == id)
                .Where(x=>x.Type == UserType.Oldfag)
                .ToViewDto()
                .ToList();


Каждый раз в тестовом методе заполнять список с UserEntity делать AsQueryable() уж
очень долго. 

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

Подскажите как правильно поступить? Или я иду в направлении интеграционных тестов
и DAL вообще не стоит трогать? 
    

Ответы

Ответ 1

Каждый раз в тестовом методе заполнять список с UserEntity делать
  AsQueryable() уж очень долго.


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


  Или я иду в направлении интеграционных тестов и DAL вообще не стоит
  трогать?


Тесты всякие нужны, тесты всякие важны. И на DAL в т.ч. Просто если у вас нет в БД
никакой логики, то тогда вы сможете замокать ее, и получить чистые юнит-тесты. Если
же в БД есть логика, то придется делать и интеграционные тесты (тут, впрочем, можно
подискутировать на тему того, стоит ли тестировать БДшный код из тестов приложения
или иметь отдельные тесты для процедур).


Ответ 2

Мне кажется, тут нужно разделять тесты DAL-а, от тестов пользователей DAL-а.

Вот, например, как протестировать приведенный фрагмент?:

_repository.Query
                .Where(x => x.Id == id)
                .Where(x=>x.Type == UserType.Oldfag)
                .ToViewDto()
                .ToList();


Для этого нужно проверить: (1) что DAL реализован корректно и (2) что связка DAL_Client
-> DAL -> Data Store работают корректно.

Разбиваем этот процесс на две части:

Тесты реализации DAL-а


Парсинг деревьев выражений
Применение предикатов для фильтрации содержимого
SQL-генератор
Работу методов Select и других методов IQueriable
Корректность работы метода ToViewDto


Данные тесты могут (и должны) использовать классы, отличные от UserEntity: для этого
подойдут дата-объекты.

Тесты связки DAL_Client -> DAL -> DataStore

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

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

Сложно сказать сейчас, есть ли смысл мокать репозиторий с UserEntity, поскольку не
ясно, будет ли при этом проверяться что-то, что еще не было покрыто в первом разделе
юнит-тестами, которые работали с произвольными дата-объектами.

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


Ответ 3

Все зависит от того насколько изменчив список с UserEntity.


Если редко, или один список на все тесты - положить данные в файл/json и грузить
данные в каждом тесте.
Если каждый тест - свой список - использовать много файлов или использовать аналог
approvaltests