Test-driven development

[juan_gandhi]

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

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

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

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

Comments

[sab123.livejournal.com]

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

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