Как тестировать DAL слой с помощью Unit тестов?

Question

[Дмитрий]

Здравствуйте! Подскажите как лучше протестировать слой DAL, есть слой DAL, и проект DAL.Test содержит тесты для него, в слой DAL добавлен Entity Framework, нужно ли добавлять Entity Framework к проекту DAL.Test, или же DAL.Test ничего не должен знать про Entity Framework и должен только вызывать методы из DAL? А если не добавлять Entity, то тогда как протестировать репозитории, которые находятся в DAL

Comments

[Валерий Абакумов]

Добрый день! Если честно, не вижу особых причин для юнит-тестировагия слоя DAL. Что Вы будете юнит-тестировать в слое DAL? EntityFramework? Зачем, его уже до Вас несколько раз протестировали. Юнит-тестами в первую очередь нужно покрывать бизнес-логику, ну и кдассы доменной модели заодно. А если Вы хотите тестировать репозитории из DAL, то конечно же, это нужно делать без какой-либо привязки к EF (Moq в помощь).

[Дмитрий]

Валерий Абакумов: в DAL тестировать репозитории

[Дмитрий]

Валерий Абакумов: а почему нужно делать без привязки к EF ???

[Валерий Абакумов]

Дмитрий по идее, юнит-тестирование какого-либо модуля должно происходить в изоляции от других компонентов, чтобы юнит-тест мог нам подсказать, что "функциональность этого модуля работает корректно, независимо от окружения". Если изолировать компоненты друг от друга нельзя, значит, компоненты сильно связаны друг с другом, что влечет за собой увеличение стоимости проекта из-за увеличения трудоемкости сопровождения проекта, т.к. изменения в сильно связанных компонентах очень дорогие по ресурсам. Соответственно, решение проблемы лежит в абстрагировании компонентов друг от друга. А если компоненты абстрагированы, то их легче сопровождать, вносить в них изменения, а значит, легче формировать изолированные юнит-тесты. Тест, который проверяет какую-то функциональность не в изоляции от каких-либо компонентов (т.е. такой тест зависит от конкретного окружения), становится интеграционным тестом. А это, обычно, уже более сложные тесты, которые проверяют взаимодействие нескольких функций, нескольких компонентов.

[Дмитрий]

Валерий Абакумов: к примеру мы используем репозитории, которые завязаны на EF, в котором создается экземпляр контекста и дальше с ним работает, в таком случае есть ли смысл рефакторить приложение для того чтобы замокать контект, ведь этот репозиторий реализует конкретныый доступ к данным за счет EF

Answer 1

[Толстый Лорри]

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

Comments

[Дмитрий]

т.е DAL.Test должен заниматься только тестированием и не должен иметь никаких лишних ссылок на всякие тулзы типа EF ?

[Толстый Лорри]

Дмитрий: Желательно сводить зависимости к минимуму, иначе юнит-тест превращается в интеграционный.

Если работаете с ASP.NET MVC, то я хочу порекомендовать вдумчиво почитать книжку Адама Фримана (smarly.net/pro-asp-net-mvc-4), там по ходу действия книги пишут интернет-магазин и параллельно пишут тесты. Очень наглядно можно посмотреть, как построен фреймворк и как дробить свою архитектуру.

Answer 2

[Александр Рыжов]

Для тестирования DAL, если он полностью использует для сохранения и доступа к данным только методы EntityFramework, можно не использовать реальную базу, а воспользоваться Effort. Но для этого необходимо создать тестовый DbContext, который бы использовал эту библиотеку.
DAL.Test должен референсить все, что необходимо для создания реального тестируемого класса (например репозитория) и фейка для DataContext, который бы внутри себя использовал Effort.

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