public void Foo (DbConnection db, UserProvider provider)
{
    UserService srv = new UserService (db);
    
    User user = srv.GetUser (provider);
    if (user != null)
    {
        user.Login ();
    }
}

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

Если тестировать на объектах, то тест может стать крассным из-за ошибки в GetUser, а значит написанный тест тестирует все, что угодно, но только не фунцкцию Foo :)

Правильный вызов логина на объекте юзер - прерогатива объекта юзер. Вот в юните для него пусть и тестируется. А так вы в любом месте вызова логина будете этот вызов тестировать? В пяти разных местах будет - в пяти местах будете тестировать, хотя вызов зависит лишь от объекта юзер, который находится в одном месте.

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

Если бы изолированные тесты с моками работали как в теории, то не нужны были бы интеграционные тесты, т.к. вы фактически тестируете интеграцию объекта user в функцию Foo. А раз у вас есть интеграционные тесты, значит вы не доверяете даже изолированным юнит тестам. Тогда смысл тестировать, если нижележащие объекты не проходят тесты? Вот когда начнут проходить, тогда и оттестируете. Нет никакого смысла в правильности функции Foo, если неправильны используемые ей объекты. А пока это получается самоуспокоение и лишняя работа - тестировать то, что потом всё равно будет перетестировано интеграцией. Может, вы хотите покрытие юнит тестами больше 100%? По-моему, это легко осуществить, продублировав все тесты по нескольку раз для разных мест.

Вообще, странно, что принципы программирования, а конкретно единственность ответственности, у вас легко нарушаются в тестировании, и вы ответственность одного объекта легко размазываете по всем другим местам, где этот объект используется.