Test-driven development

[juan_gandhi]

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

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

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

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

Comments

[birdwatcher.livejournal.com]

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

[trurle.livejournal.com]

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

Вот здесь, например

[object.livejournal.com]

http://www.agiledata.org/essays/tdd.html

[alll]

Kent Beck, Test Driven Development: By Example

[object.livejournal.com]

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

[darypola.livejournal.com]

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

[alll]

Такое впечатление, что вы путаете юнит-тесты с функциональными. Если считать, что сказанное вами сказано о функциональных тестах, то полностью согласен. Если о юнит-тестах - несогласен категорически. :)

[darypola.livejournal.com]

Я вообще-то рассуждала о том, когда на написание тестов полезно тратить ресурсы, а когда бессмысленно и даже вредно. Тесты - здесь общее понятие. Разве при равных условиях, например, разработке серии прототипов на ранней стадии проекта, на юнит тесты было бы уместно тратить такой невосполнимый ресурс как время, тогда как на функциональные нет? Нет, усилия затраченные на оба типа тестов уйдут впустую, потому как прототип с большой долей вероятности будет просто отклонен, а даже если и принят, то все равно его слишком упрощенная архитектура не годится как базовая для дальнейшего развития проекта, следовательно не годятся и тесты к ее компонентам. А чем чревато затягивание фаз разработки продукта я уже писала в посте выше.
Еще раз повторю, мне нравятся unit тесты, но это не Silver bullet :).

[alll]

Объединение юнит-тестов и функциональных тестов в "общее понятие" имеет приблизительно такой же смысл, как объединение в "общее понятие" снотворного и слабительного - лекарства, как-никак. И общие рассуждение об этих общих понятиях иногда напоминают результат одновременного приёма вышеупомянутых лекарств. :)

Прототип - если это то, что будет спущено в канализацию сразу по использовании без попыток повторного использования кода в непрототипе и при этом достаточно мелок, чтобы уместиться в одной голове, - в юнит-тестах действительно не нуждается. Детские куличики тоже не нуждаются в контроле качества.

Но как только пошёл код, имеющий шанс попасть в продакшн - юнит-тесты окупаются хотя бы тем, что если их нет изначально, то переделка кода под них скорее всего будет выглядеть настолько дорого, что утопит всю идею юнит-тестирования.

[darypola.livejournal.com]

Хотелось бы побольше конкретики. А пока только голословные высказывания по поводу недопустимости объединения тестов разного вида под одним термином. Было бы интересно узнать, почему Вы считаете, что мои три пункта правомерны для тестов одного типа и неправомерны для другого, с убедительной аргументацией.

Почему такое ироничное отношение к стартовым версиям продуктов? Любая сложная система начиналась с такого вот куличика.

Шансы кода попасть в продакшн - по сути вероятность, она растет с приближением финиша проекта. Предсказать попадание туда какого-либо кода однозначно нельзя. Какие особенные переделки требуются в нормальной архитектуре, чтобы к ней можно было применить юнит-тестирование? Переделки потребуются если почти вся функцинальность сосредоточена в нескольких громадных классах с громадными методами - ну так это плохой дизайн, и даже без расчета на последующее юнит-тестирование не следует такую архитектуру использовать.

[ivan-gandhi.livejournal.com]

Во всяком проекте наступает такой момент, когда надо что-то писать. Ну пока пишется одна шелуха, то можно тестов и не писать. Но потом начинается содержательная часть. "Интересные случаи", как говорит Джош Керевский. Вот на интересные случаи и надо сразу же делать тесты. Чтобы потом не возвращаться сто раз к элементарным вещам, не тратить дикое количество времени на трассирование.

Затягивание же фаз разработки продукта... Мой опыт показывает, что всё фигня. Когда готово, тогда и готово. Главное - процесс и удовольствие от него.

[sab123.livejournal.com]

Не, ну на самом деле писание подробных тестов занимает больше времени, чем писание собственно программ. И то, что любые изменения в функциональности программы норовят попортить тесты, приводит к тому, что стоимость этих изменений тоже умножается примерно на два. Но зато все работает, и все будущие поломки сразу отлавливаются.

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

[darypola.livejournal.com]

Ну интересные случаи я тоже бы выносила отдельно в рамочку для потомков. Тесты писать к ним действительно интересно. Большинство же - рутина, которая меняется по нескольку раз в неделю, ее покрывать тестами - очень расточительно.
Затягивание момент неоднозначный. Мне как исполнителю конечно удобно быть не иметь временных ограничений, но удобство заканчивается, когда надо что-нибудь поручить или заказать - ожидать выполнения критичного задания неделями совершенно неприемлимо. Иногда у качества слишком дорогая цена.

[alll]

Тогда давайте попробуем перейти от общего к частному и определить, какое отношение п.1 имеет к юнит-тестам.

Затем сделаем то же самое для п.2.

Затем сделаем то же самое для п.3.

Будем?
Или пустая трата времени?

[darypola.livejournal.com]

Кажется по пунктам как раз только я и высказалась. Пункты будут неверны для юнит-тестирования, если стоимость юнит-тестов окажется равной нулю. Очень хочу услышать, каким образом стоимость теста может быть нулевой.