petalvikНа мой взгляд, главный миф о TDD - то, что тесты нужно писать раньше кода. Это теоретически невозможно!
Сейчас обосную!

В мелких статейках и бложиках многие программеры, едва познакомившиеся с юнит-тестированием, нахватавшись разных (глупых) идей, начинают кукарекать: сперва тесты, потом код!
Но ни в одной серьёзной нормальной большой статье, а тем более в книгах по тестированию я не встречал такой бред. Если кто знает такую книгу - упомяните.

Да, мне неоднократно пытались доказать, что они сперва пишут тесты, а потом код. При внимательном изучении всегда оказывалось, что это не так. Возможны два случая:
1. В прошлом этот разработчик уже писал похожий код в подобном проекте; поэтому в нынешнем проекте он автоматически переносит куски кода оттуда; в таком случае действительно можно сперва написать тесты, а потом код; но на самом-то деле код уже был написан ранее!
2. Сперва ведётся тщательнейшее проектирование, расписывается до мелочей взаимодействие модулей, всё чуть ли не до локальных переменных определено. Пример такого проектирования описан в книге Крэга Лармана "Применение UML и шаблонов проектирования". Дальнейшая работа сводится к тупому кодированию. Вот теперь, после проектирования, можно написать тесты, а потом код. Но тесты не были первыми! Сперва был проект!

Одной из культовых книг считается "Рефакторинг" Фаулера. Если её почитать, то он по ходу повествования постоянно переносит код из одного метода в другой, потом в другой класс, выносит параметры в поля, потом обратно, через несколько итераций возвращает метод в первоначальный класс, но уже с другими параметрами... Вот как тут писать тесты? Написал и тут же выкинул.
Да, если мы не уверены, что в процессе рефакторинга ничего не сломаем, то сперва нужно написать тесты. Но это на уже работающий код. А если код ещё не работает, даже не компилируется, если мы ищем способ как вообще его написать - о каких тестах может идти речь? А если тесты всё же очевидны, тот тут смотри выше два описанных случая: либо похожий проект писался раньше и поэтому код (большая его часть) заранее известен, либо было проведено тщательное проектирование (сперва проект - затем тест и тупое кодирование).

Или вот, например, презенташка http://blacksheep.parry.org/wp-content/uploads/2010/03/State-of-the-Art-Testability.ppt (Java)
Изначально было три класса. Постепенно, в ходе рефакторинга кода для улучшения тестирования (а также уменьшения связности, внедрения зависимостей и пр.) классов стало восемь. Нужно ли было писать тесты на первые три класса? При условии, что вся эта работа по написанию кода была проведена за один день? Имхо, это бессмысленно, да и невозможно: в первой версии методы внутри себя создают другие классы и их нельзя подменить/замокать.

Можно ли было написать сразу конечную версию с восемью легко тестируемыми классами? Можно! При этом сперва можно (и нужно) написать тесты. Казалось бы, я противоречу сам себе (смотрите тезис в первом абзаце). Но дело в том, что чтобы дойти до такого дизайна нужно сперва наломать кучу дров, написать тысячи строк хрупкого сильносвязанного кода, набить шишки. То есть сперва - код! И лишь затем, по прошествии месяцев или лет, набравшись опыта, научиться сходу проектировать легкотестируемый код. То есть, опять же: вначале по-любому будет код - в голове разработчика, код из предыдущих проектов, из опыта. А тесты - потом.


прям мои мысли один в один :)