Комментарии 9
Если Вы откроете кран и начнёте заливать в меня десятки правил и выводов, я «переполнюсь» всего за паручасовминут.
По-моему, пара часов это слишком оптимистично.
Подход к изучению TDD через исправление багов, описанный автором, хорошо работает в том случае, если приложение изначально написано достаточно грамотно. В нём выделены модули и обеспечена сравнительно малая связанность между ними. Если же вам досталось что-то, что напоминает неструктурированный процедурный код, в котором всё зависит от всего остального, то ситуация становится гораздо сложнее. Для написания теста необходимо изолировать кусок кода, в котором содержится баг, от других частей приложения, иначе тест будет занимать несколько десятков экранов и будет совершенно не читаем (если его вообще будет возможно написать). Для этого необходимо провести массовый рефакторинг этого кода. Без существования уже написанных для него тестов, подобный рефакторинг может породить ещё более существенные баги, чем тот, который необходимо исправить. Получаем замкнутый круг. Дело осложняется при сложности проведения рефакторингов, к примеру, при работе с C++, или JavaScript.
На мой взгляд, изучать TDD проще всего с написания сравнительно независимых от других частей программы компонентов. Единственные минус данного подхода в том, что не все настолько удачливы, чтобы иметь такую возможность.
На мой взгляд, изучать TDD проще всего с написания сравнительно независимых от других частей программы компонентов. Единственные минус данного подхода в том, что не все настолько удачливы, чтобы иметь такую возможность.
Тут сложно возразить. Да, с таким кодом работать реально сложно. Но автор в данном случае говорит: определите для себя, где Вы можете применять TDD, а где нет. Если в коде всё совсем плохо, но его при этом надо каким-то образом поддерживать, есть свои способы вводить TDD. Например, создавать новый функционал через тесты, а потом использовать его в существующем коде. Так намного легче управлять зависимостями.
Либо начинать тестирование на более высоком уровне (если есть такая возможность). Например, если мы работаем с веб-приложением, то первые тесты можно написать через веб-интерфейс с помощью WebDriver (или альтернатив). Они позволят хотя бы гарантировать, что наши рефакторинги не сломают приложение полностью. Имея такие тесты, уже можно потихоньку пробовать решать проблемы связанности кода.
К сожалению, мой опыт показывает, что люди часто используют аргумент «наша система слишком сложная», чтобы не проводить юнит-тестирование в принципе. Соответственно, у них не возникает потребности улучшать дизайн кода, не возникает потребности улучшать его тестируемость. Отсюда и возникает замкнутый круг. Мне кажется, это проблема больше психологическая, нежели техническая.
Либо начинать тестирование на более высоком уровне (если есть такая возможность). Например, если мы работаем с веб-приложением, то первые тесты можно написать через веб-интерфейс с помощью WebDriver (или альтернатив). Они позволят хотя бы гарантировать, что наши рефакторинги не сломают приложение полностью. Имея такие тесты, уже можно потихоньку пробовать решать проблемы связанности кода.
К сожалению, мой опыт показывает, что люди часто используют аргумент «наша система слишком сложная», чтобы не проводить юнит-тестирование в принципе. Соответственно, у них не возникает потребности улучшать дизайн кода, не возникает потребности улучшать его тестируемость. Отсюда и возникает замкнутый круг. Мне кажется, это проблема больше психологическая, нежели техническая.
На мой взгляд, если не предпринимать усилий по улучшению дизайна системы, то после некоторого момента стоимость внедрения тестов начинает превышать стоимость полного, или частичного её переписывания с нуля. С другой стороны, хороший дизайн можно поддерживать не только с помощью TDD, но и другими методами, к примеру частым code review.
Насчёт психологической проблемы согласен, многие просто не понимают, зачем нужно TDD и юнит-тесты вообще. Обычная отговорка, что система (если говорить о поддержке) как-то была написана и даже работает без каких-либо подобных техник.
Насчёт психологической проблемы согласен, многие просто не понимают, зачем нужно TDD и юнит-тесты вообще. Обычная отговорка, что система (если говорить о поддержке) как-то была написана и даже работает без каких-либо подобных техник.
после некоторого момента стоимость внедрения тестов начинает превышать стоимость полного, или частичного её переписывания с нуля
Вот только непонятно обычно, когда этот момент наступает :) Это как горизонт чёрной дыры: ты ещё не знаешь, что его пересёк, а обратного пути уже нет.
Конечно, такой проект вряд ли стоит использовать для изучения TDD. Тем не менее, я не думаю, что большинство проектов в индустрии можно сравнить с чёрными дырами. Скорее, они находятся в более-менее приемлемом состоянии. И в таком случае внедрение TDD по совету J.B. пойдёт, как мне кажется, на пользу и тем, кто TDD внедряет, и самим проектам.
Обычная отговорка, что система (если говорить о поддержке) как-то была написана и даже работает без каких-либо подобных техник.
Работать-то работает, просто стоимость внесения изменений (с учетома проверки регрессии и правки каскадных ошибок) не радует.
В вебе, даже если дизайн системы безвозвратно испорчен тесты на тупую доступность страниц уже приносят ощутимую пользу. Это вообще такая отрасль где без тестов жизнь очень печальна.
Так, что, если не ставить перед собой задачу покрыть все тестами, а хотя-бы облегчить себе жизнь, то стоимость внедрения — 1 вечер.
Так, что, если не ставить перед собой задачу покрыть все тестами, а хотя-бы облегчить себе жизнь, то стоимость внедрения — 1 вечер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучение TDD через интенсивную практику