Выцепил сегодня у Кента Бека классную фишку: когда делаешь code review или pr-обзор, не тыкай прямо в ошибку, если такая есть. Подскажи, какой тут тест пропущен. Кодер не должен тупо фиксить тикеты, он должен думать прежде всего, быть хотя бы немножечко в контексте проекта.

Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)

Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.

Десятки других фишек от кента разберём с ментатами в СИ.