Гыук,

У нас такие части обычно изолированы, нет нужны какой-то большой кусок тестировать, с классами, которые нельзя замокать или подсунуть стаб. Поэтому такими фреймворками не пользуемся :)

ГыукНе могли бы уточнить, Вы не пользуетесь, потому что что-то типа такого фреймворка у Вас уже есть?

Нет, нету, не зачем.


ГыукИли этим фреймворком вообще надо пользоваться в исключительных случаях.

В случаях, когда работаешь с чужим кодом, написанным очень плохо.

ГыукИ, второй вопрос, по юнит-тестам, пользуетесь ли Вы моками на сущности EF? Или все запросы к EF просты, и без логики?

В проекте, который написан с использованием EF, у нас EF абстрагируется от остального кода интерфейсами репозитория, типа IRepostory. Так как никто больше не имеет прямого доступа к EF, мы можем мокать наши интерфейсы. Саму реализацию таких интерфейсов, которая используют EF, тестируем на реальном EF контексте с базой данных InMemory (SQLite). Проверяется, что методы репозитория правильно выполняют свои функции. При этом не тестрируется, что сам EF работает правильно, например, работает ли ChangeTracking и проч. Это всё тестируют сами разработчики EF.

Также по поводу EF, есть следующий пост

https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx

ГыукНапример, если надо какую либо выборку сделать для отчета по нескольким таблицам, с подсчетами итогов, и т.п. - пишется ли на такой метод/класс юнит-тесты?

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