pletinsky

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

Материалы я думаю вы без труда найдете — их завались по этой теме.
На мой взгляд самое главное следующее — для TDD требуется особый подход к мышлению во время написания кода. И именно этот подход делает его эффективным. Заключается он в том, что вы не пытаетесь полностью выстроить в голове работающий метод, который создаете. Вместо этого вы выделяете отдельные бизнес составляющие метода — и создаете их поэтапно.

Профит в том, что у человека не хватит ума охватить целиком весь бизнес даже довольно простого метода (хотя он думает иначе разумеется) — отсюда появляются проблемы при дальнейшей поддержки метода, баги, переусложненные методы, код который имеет низкое или нулевое бизнес значение и т.д.

Например вы делаете метод который вычисляет корень из числа… Напишите простой тест подавая туда число 4 и ожидая что на выходе будет 2. Далее имплеминтируете функционал добиваясь чтобы тест прошел.
Но ничего лишнего там писать не стоит. Потом пишите следующий тест например на реакцию на отрицательные значение — далее имплементируете функционал. И так далее.

То есть это метод мышления. Самому к этому прийти не получится — самый лучший вариант — нанять человека который уже это умеет и научится сидя с ним в паре. Если это не возможно — попытайтесь понять стиль такого кодирования использую пособия на реальных ситуациях вроде этого.

Вот тут описаны проблемы при использовании подхода.

TDD — это не метод тестирования — а метод разработки. Он требует архитектурной готовности системы.
При тестировании модуля (например метода или класса) обязательно избавьтесь от всех внешних зависимостей путем мокирования.
Лучше ввести это как жесткое правило — потому, что оставлять такие зависимости можно только в редких случаях и когда вы уже прошарены в теме и что называется знаете — где правила можно нарушать.

Не ленитесь разрабатывать по шаблону — соблюдая мельчайшие и даже самые странные правила — даже если вы видите потерю эффективности — и со временем вы научитесь применять данный инструмент.

То есть можно конечно привязаться к разным уровням приложения в тестах — но в данном случая как я понимаю — вы не можете привязаться ни к чему — поэтому предлагаю привязаться к самому верхнему уровню из возможных, рассматривая внутренности приложения как блек бокс.
Все остальное очень зависит от делатей самого проекта — почему у вас там не получается оргинизовать подобие интеграционных тестов.

Если вы не можете сделать моки — то речь вообще не о юнит тестах и обычные фреймворки для юнит тестов вам могут не помочь. Юнит тесты это тесты на отдельные модули — обычно на методы класса в отрыви от внешнего окружения.
Не только от базы данных — а вообще от всех других классов.
И если так подходить к делу — то вам должно быть наплевать на то что юнит тесты чего то там не подтягивают.
Юнит тесты предполагают архитектурную готовность системы и обычно пишутся до кода в рамках TDD.

Если хотите сделать приложение стабильным — в вашем случае нужны behaviour тесты. Просто разворачивайте приложение как будто это делаете на продакшене — и тестируйте все его поведение в целом эмулируя действия пользователя на вебе.