Test-driven development

[juan_gandhi]

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

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

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

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

Comments

[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]

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