ТДД - это больше о дизайне, а не о тестировании. Есть у Kent Beck слова, где он говорит о том, что TDD - это не о тестировании. Тесты просто позволяют фокусироваться на одной обязанности, осуществлять поиск решения путем обобщения и триангуляции. Это снижает нагрузку на мозг и позволяет быстрей найти удачное решение.
В сериале "Is TDD Dead?" Kent Beck говорит о том, что 100%-е покрытие и не требуется. Покрытие должно быть достаточным для обретения уверенности. Более того, тесты должны облегчать рефакторинг, а не сковывать его, поэтому тесты не должны покрывать реализацию, иначе они превратятся в оковы.
По поводу парадигм - разные парадигмы имеют разные превосходства в разных контекстах. Есть у B.Meyer замечательная статья, в которой он пишет, что используя принцип CQS мы обретаем возможность пользоваться превосходствами обоих парадигм ситуативно, в зависимости от контекста, т.е. OOP отлично сочетается с FP.
Кстати, рассвет TDD пришелся на этап становления OOP, причем, в динамических языках. Возросший уровень косвенности и отсутствие современных статических анализаторов затрудняли навигацию в коде и разработку без TDD. Я застал времена, когда нужно было в консоли емакса объявлять переменную, чтобы её тип подхватился в буфере редактирования файла с Python-кодом. И я был одним из тех, кто добавлял в emacs типизацию (вернее, Type Hinting) для Python, в то время еще через docstrings. Это уже позже в Python появилась типизация через аннотации.
Сегодня этой проблемы уже нет даже в динамических языках, и это снижает потребность в TDD. Но, по личному опыту могу сказать, что используя TDD можно быстрее написать качественное решение, чем без него.
По личному опыту могу сказать, что при использовании TDD я отладчиком практически не пользовался. Да и вообще, если есть юнит-тесты, а не только ТДД, то потребность в отладчике сильно сокращается, и это хорошо, потому что время на написание тестов можно прогнозировать, в отличии от отладки. Кстати, в большинстве случаев время на написание тестов полностью перекрывается повышением темпов разработки, т.е. разработка с тестами получается даже быстрей. Пальцы работают больше, а голова меньше. Происходит просто перераспределение составляющих разработки.
Лет 15 назад с научным руководителем рассуждали о недостатках ООП
Пришли к выводу, что в ООП проигнорирована объективность функциональности
Функция уборки существует независимо от того, есть уборщица в организации или нет
В ООП функции не могли существовать как самодостаточные объекты
Теперь всё изменилось. И конечно здорово, что в рамках одного ЯП общего назначения можно комбинировать парадигмы
То есть вопрос должен ставиться не как противопоставление парадигм, а наверно где границы их применимости (для каких задач удобно)
