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

Сначала надо ответить на вопрос "что мы тестируем". Если мы тестируем функцию Login, то unit under test - объект юзер. В данном случае unit under test - функция Foo и правильно ли работает объект User не имеет никакого значения, т.к. у Foo есть своя логика и именно ее мы тестируем.

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

Нет. Это уже будут не юнит-тесты. Юнит-тесты - атомарны и не должны зависить ни от каких других тестов или инфраструктуры.

Если бы изолированные тесты с моками работали как в теории, то не нужны были бы интеграционные тесты, т.к. вы фактически тестируете интеграцию объекта user в функцию Foo.

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

Когда я пришел на прошлый проект, там было около 30 интеграционных тестов, которые исполнялись около 2,5 часов. Я добавил в проект около 1000 юнит-тестов, которые выполнялись всегда вместе с компиляцией и требовали меньше 5 минут времени. При этом юнит-тестами можно покрыть гораздо больше тест-кейсов. Например, я в том проекте добавлял проверку на отказ в правах доступа жесткого диска. Сделать такое в интеграционном тесте очень сложно.

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

Это не так :)