Test-driven development

[juan_gandhi]

Люди любят удивляться этой идейке, мол, красиво, да, но я так не могу, мне сначала код надо написать да поотлаживать.

А я поставил опыт на себе - написать код, и не отлаживать его, а всё через тесты прогнать. Так, чтобы вообще не трассировать никакое поведение, а просто смотреть, какие тесты рухнули, и если они не дают достаточно информации, то модифицировать код и тесты.

Что получается. Код должен состоять из мелких очевидных операций. Как на картинке. Чтобы тест был тоже элементарным. И если код что-то компилирует (тссс, да, у меня и компилятор внутре имеется - Ватсон знает, о чем речь), так два теста нужно: один на фазу компиляции, другой - на фазу исполнения компилированного участка.

В идеале чтобы пальцем тыкать, если при рефакторинге что-то сломалось: "вот тут у тебя не работает". Просто из логов чтобы видно было.

Comments

[birdwatcher.livejournal.com]

Заодно любая программа принимает вид таблицы, где по номеру теста хранится текстовая строка, которую надо вывести на печать для успешного прохождения данного теста. Если на каких-то тестах программа ломается, в таблицу надо добавить рядов.

[trurle.livejournal.com]

А где про это можно почитать? Я пробовал пользоваться JUnit или как он там называется, но как то не превозмог.

[object.livejournal.com]

Ну да. Я так уже пару лет работаю. Все стало гораздо проще. Особенно regression test.

[darypola.livejournal.com]

Вообще-то я за тесты, но против злоупотребления ними. Повсеместное TDD на ранних стадиях развития проекта причисляю к таковым. Поясню почему:
1. Предварительное написание тестов перед каждой модификацией системы очень сильно снижает интерактивность взаимодействия с заказчиком или хозяином проекта. На ранних этапах суть проекта еще не определена точно, обычно она устаканивается после нескольких итераций на которых заказчику предъявляется прототип-набросок системы, отражающий его текущие требования. Чем быстрее будут делаться и предъявляться такие наброски - тем лучше, иначе стороны просто будут забывать о чем шла речь, им придется каждый раз начинать обсуждение с нуля. А это значит, что пострадает качество постановки задачи, т.к. бесконечно долго определяться с требованиями нельзя. Ну и огромное количество труда будет потрачено впустую, т.к. демка помимо презентаций нигде использоваться не будет.
2. Даже если проект уже на средней стадии развития, все равно страдает интерактивность взаимодействия между разработчиками. Предположим два разработчика активно пишут 2 подсистемы одной большой системы, взаимодействие этих подсистем сложное. Разработчики, конечно, совещаются, чертят вместе функциональные схемы, но в тонкости архитектуры чужой подсистемы не влезают, т.к. своих дел тоже хватает. После нескольких месяцев напряженной работы по TDD они наконец-то решают стыковаться - и, вуаля, каждый сделал немного не так, как понимал это другой, - состыковка не получилась, надо переделывать. Опять куча времени и сил ушла не в том направлении.
3. Низкая доступность улучшений или рефакторинга архитектуры. При наличии всеохватывающей инфраструктуры тестов, рефакторинг становится очень болезненным процессом, на который разработчик пойдет в крайнем случае, только если клюнет жареный петух. А до этого времени будет надеяться, что срастется и так.
Я не против тестов, я за умеренное их использование. Они хороши на финальной стадии проекта или на любых стадиях, но только для критических его частей, неправильная работа которых может нанести непоправимый вред. Имхо, TDD - не панацея, просто trade-off между безопасностью и оперативностью.