ну во всяком случае, есть хотя бы тестирование )))  и это очень хорошо !

мокать бд звучит мощно. мокать DAO-слой - еще туда-сюда

Мокать DAO слой тоже довольно странно. По сути получается прослойка моков сложнее основной логики (и с большим количество ошибок). Так что прохождение тестов не будут говорить о качестве основной логики. Ну и дорого безумно.

Я еще не разу не видел примера TDD для действительно сложной логики.

думаю не в каждом классе есть внешние источники

Ну, вот для тех классов, которые изолированы - и пишем Unit-тесты. Но их получается очень мало.

Увы, но в реальной жизни большая часть бизнес-логики предполагает интеграцию с кучей внешних источников - внешних сервисов, баз данных, МQ и т.п.

зачем как-то особенно тестировать mq, вы же тестируете конкретные методы, на взод пришло это ожидается получить то

когда mq тогда уже интеграционные

но модульными вы тестируете минимум логики, заложенной в том или ином методе

Ну, вообще работа с  mq - это почти всегда всякие Future и прочие примитивы синхронизации по событиям вне класса.

так в модульных это учитывать не надо

А тогда содержание модульных становится пустым.

Потому что TDD как раз помогает сдерживать сложность в разумных рамках.

Эээ, пока таких примеров тоже не видел. Усложнение структур данных для TDD - видел.
А вот уменьшение сложности именно из-за TDD - ни разу.

А вот уменьшение сложности из-за необходимости поддерживать интеграционное тестирование и разработки через пример использования - видел, это да )
Но к TDD это не имеет отношения.

С одной стороны- надо делить бизнес-логику на части.
Т.е. метод "когда по шине получили такое сообщение то послать в другие шины другие сообщения" достаточно легко делатится на части "метод получает объект сообщения и возвращает список пар очередь-сообщение".
Вот когда надо "сбегать в БД и получить данные"- тут сложнее. И чтобы не мочить БД приходится писать кучу сервисов "дай объект по фильтрам", которые либо бегают в БД, либо в мапу/инмемори БД/...
Главне- как говорит Егор- писать не моки а стабы :D

Вот когда в логике вместо нормальных бизнес-сущностей появляются всякие "списке пар очередь-сообщение", поддерживать код становится страшно.
Сила Java в строгой типизации и поддержки IDE. Любые попытки сделать из Java какой-нибудь javascript (ради практик, из динамических языков и пришедших) приводят к страшным последствиям.

Дай объект по фильтрам мочить легко (и обычно не нужно). А вот изменить объект в транзакции и корректно обработать возможные проблемы - уже мочить сложно и, обычно, вредно.

И не понятно, ради чего )