Чо это?

Это подход, когда мы обязываемся писать тесты, до написания кода. То есть мы придумали фичу, придумали как ее тестировать, написали тесты и только потом пишем код.

А нахуя?

  1. Супер часто вы будете в ситуации, когда хуй проссышь как тестить-то говно, которое вы напридумывали. И в 100% случаев это будет означать, что проблема не в задаче, а в том, что вы сами не понимаете, че вам надо. То есть TDD потрясающе помогает нам валидировать задачи и сокращает кол-во ситуаций, где менеджер после сдачи таски говорит: "а это ваще че? я другое просил?" 🤡
  2. Проект стремится(!) к 100% покрытию тестами и это, иногда, хорошо.
  3. Мы сокращаем кол-во крашей после обновления старых модулей приложения, так как наличие "большого покрытия" иногда будет открывать внезапные проблемы в других модулях. Ну, типа, не регресс тестинг, но хотя бы шанс, что если мы накосипорили и повлияли на другие куски кода, то рандомные тесты отъебнут и мы не зарелизим кал в прод.
  4. На практике подтверждено, что введение TDD, заставляет лучше думать на планировании и атомарность задач повышается, как и качество архитектуры.

А че по факту?

  1. Вы будете писать дахуиющу тестов, там где они нахуй не нужны
  2. Ага-да, попробуйте эту хуйню к старому монолиту прикрутить. Если TDD не со старта проекта или, как минимум, проект не расписан на микрокуски – очень трудное внедрение
  3. 100% покрытие не всегда реально
  4. Чаще всего, люди будут хуевить и покрывать все юнит тестами. И всё.
  5. И даже юнит тесты будут состоять из стабов более, чем полностью, если регулярно не давать пизды своим гребцам.