#c_sharp #юнит_тесты
К примеру есть классы с такими extension методами: IQueryableToViewDto(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