В начале было слово или почему ТДД невозможно
Для экономии времени
Действия бывают понятные и правильные. Написание кода, а потом тестов — это понятное действие.
Предыстория
В группе Technical Excellence RU подняли интересный вопрос о том, что «ТДД — это попытка вытащить себя за волосы. Перед тем как строить высказывания, нужно написать первую версию словаря, то есть кода». Речь идет о том, что мы не можем определить образ результата — он недостижим, пока не дойдем до него. Вот сейчас обидно стало.
Определим словарь
Тестирование — валидация/верификация программного обеспечения, имеющее своей целью проверку соответствия между фактическим поведением программы и её ожидаемым поведением.[2]
Разработка через тестирование (англ. test-driven development, TDD) — техника разработки ПО, основанная на повторении коротких циклов: сначала пишется тест, покрывающий желаемое изменение, затем код для его прохождения, а в конце — рефакторинг.[1]
Переводим с «википедического» на русский: мы формируем образ результата (ожидаемое поведение), материализуем его в тест, пишем код для достижения цели и повторяем цикл, пока набор тестов не совпадет с изначальной постановкой.
Выглядит просто и прибыльно: и код есть, и тестами покрыт. В чем же проблема и сколько их.
Проблемы ровно две
Нет потребности
Тут всё ясно: если суть постановки не важна («код есть код»), то осознавать и «постигать» результат незачем. У нас жесточайший дедлайн и для нас важен каждый квант времени
Слишком сложно
То, что слышно чаще всего. У нас <нужное вписать> очень сложно потому что <нужное вписать> и из за этого тесты написать сначала нет возможности. Отвечу вопросом на вопрос, а почему у вас постановка не декомпозирована?
У постановки есть критерии приемки, по которым будет проводиться тестирование результата, если их нет вы не понимаете, что вы делаете. Постановка слишком сложная для вас, нужна декомпозиция. И декомпозировать нужно ровно до тех пор пока у постановки не появится понятный критерий приемки. Понятный это значит вы можете написать тест на эти критерии приемки. Если это условие соблюдено, то можете приступать к ТДД. Постигли общее, постигните и частное. Очень странно что Кент Бек об этом условии ни слова не сказал.
Для полноты картины, классика, как все используют ТДД. Вы идете от частного к общему. Если же вы пойдете от частного к общему. Метафора: представьте глыбу это постановка задачи. Мы пытаемся отколоть маленький кусок (понять и написать тест) и так делаем раз за разом. Но в какой то момент у нас не получается отколоть кусок или же кусок который мы откололи слишком большой. Мы не можем с этой громадиной ничего сделать. Мы превысили сложность нашего понимания. Мы в ступоре. Нам надо декомпозировать этот огромный кусок, а мы к этому не готовы. Это же практически начинать сначала. И мы просто говорим, ТДД это не для нас.
Повторюсь. ТДД будет прекрасно работать только в том случае если мы можем четко определить результат, у нас есть виденье целого. Тогда мы сможем прийти к нему через ряд итераций. Но это крайне контр интуитивно и не понятно, а вот писать код это понятно....
[1]: Разработка через тестирование
[2]: ISO/IEC TR 19759:2005