Test-driven development

[juan_gandhi]

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

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

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

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

Comments

[ivan-gandhi.livejournal.com]

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

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

[sab123.livejournal.com]

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

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

[darypola.livejournal.com]

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