• Серверное программирование

Web Software Developer, Teamlead. Занимаюсь коммерческой разработкой около 6 лет. За это время успел проработать фрилансером, разработчиком в продуктовой компании и разработчиком в большой аутсорс-компании. Имел честь выступать на конференциях Стачка, РИТ++, DevConf, ULCAMP и большом количестве митапов Параллельно с основной деятельностью программиста занимаюсь организацией больших образовательных мероприятий для будущих ИТ-специалистов. Являюсь создателем и идеологом Форума перспектив будущего ИТ-специалиста IT Way http://it-way.pro http://vk.com/it_way

В целом большинство вещей зависит от человека, который ставит и принимает задачи в проекте. Назовём его "заказчик": в аутсорсе это - реальный заказчик или его представитель, в продуктовом - PM.
Критерии:
1. В проекте чётко описана структура интерфейсов, например, используются JSON-API, REST-API и т.д.
2. В проекте однотипный подход к реализации интерфейсов, т.е. в целом логика работы и порядок одних и тех же end-point для разных сущностей одинаковы или сильно похожи.
3. Заказчик ставит задачу и описывает в ней интерфейс, который хочет увидеть (например, заказчик технарь и сразу прописывает какие HTTP запросы, с какими параметрами и т.д.) Один из самых важных критериев. Могу объяснить, почему.
4. Задачи ставятся в стиле: одна подзадача - один тест. Очень часто встречается такое, что подзадачи - это фактически отдельные тесты (ну или пара тестов на позитивный и негативный сценарий)
5. В языке программирования или технологии есть высокоуровневый тестовый фреймворк с поддержкой интеграционных тестов, либо есть возможность использовать абстрагированный от реализации тестовый фреймворк на другом языке программирования или технологии.
6. В команде нет отдельной команды QA. Один из главных профитов TDD - ментальный. В том, что программист сперва напишет тесты на функционал и несколько раз продумает его перед тем, как начать реализацию. Если тесты будет писать другой человек, то этот профит пропадает.
7. Есть возможность использовать тестовый фреймворк с DSL по типу Cucumber, чтобы тесты заказчику можно было показывать до реализации (называю это утопичным сценарием, в своей практике не достигал, но знаю команды, которые достигали, так что держать в голове это критерий стоит).

Критерии не взаимоисключающие, некоторые даже взаимодополняющие. Необязательно проекту и команде соответствовать всем критериям, чтобы использование TDD стало продуктивным.
А также расскажу, когда TDD использовать не стоит точно!!
Вкратце:
1. Когда в поставленной задаче нет описания структуры интерфейсов (собственно, нет критерия 1 в предыдущем списке)
2. Когда реализуется незаурядная задача
3. Когда бОльшая часть задач в проекте связана с нагрузками или сложными вычислениями, результат которых сложно предсказать.

Backend и Frontend разработчиков с опытом работы от года.
менеджменту тоже будет нескучно