К основному контенту

10 причин для отказа от TDD

Давно не читал такой жестко мотивирующей статьи "10 Reasons to Avoid Test Driven DevelopmentJ
Только боюсь, что дороги после этого лучше не станут. При чем тут дороги? Читаем дальше J

Вы можете забыть о практике TDD, не писать автоматические тесты, если:

10. У вас нет клиентов.
Иногда вы делаете продукт, который никем не используется. В этом случае любые затраты на качество – это напрасные затраты.

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

8. Ваш проект короткий, простой и понятный.
Если ваша команда может закончить проект за короткий период времени (не больше нескольких недель) и не будет никогда его поддерживать, то все преимущества типа возможности повторного использования, эксплуатационной надежности и расширяемости будут потеряны для вас. Тратить время на эти вещи бесполезно.

7. Ваша архитектура безупречна.
Если больше нет способов улучшить архитектуру вашего проекта, то вам не нужно, чтобы она была расширяемой. TDD – это инкрементальная разработка, она заставляет архитектуру быть расширяемой. Если у вас все в порядке с архитектурой, то TDD вам нужен, как губная помада свинюшке J

6. У вас отличная документация.
Вы никогда не забываете API, все изменения в вашем продукте постоянно документируются. Если ваша документация настолько полная, то написание тестов противоречит принципу DRY (dont repeat yourself), потому что правильно названные и написанные тесты показывают вам все, что нужно для понимания Тесты будут дублировать документацию, поэтому не пишете тесты.

5. Ваша команда не меняется и у всех отличная память.
Коллективная память никогда не забывает ни одной написанной строчки, а также причины ее появления. Поэтому вам не нужны тесты для запоминания того, что код делает, почему он это делает и как его использовать. Это также означает, что никто в команде не покидает ее, новых людей вы не нанимаете, потому что иначе вы теряете эту память и у вас появляются люди, которые не «помнят» код. Просто их не было, когда код писался. Если все так и есть, то тесты только мешают вашей невероятной производительности.

4. «Сделано» означает, что код зачекинен.
Многие команды считают, что «сделано» определяет момент, когда фича доходит до пользователя (она закодирована, проверена, развернута, документирована и тд). Многие другие, в том числе и ваша команда, предпочитают более простое и легко достижимое определение, где «зачекинено» означает «сделано». Для вас достаточно того, что разработчик сказал, что он закончил свою часть. Все остальное – это обязанности кого-то другого.

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

2. Отладка не считается, а тестирование занимает много времени.
Вам нужно оценивать сроки, сколько времени уйдет на выпуск продукта. Так как ваше «сделано» не учитывает тестирование, а также вы не можете оценить, сколько времени уйдет на отладку, то вы оцениваете только то, сколько вам понадобиться времени закодировать это. Если вы хотите выдержать сроки, то вам нельзя накинуть 20% сверху (на всякий случай), иначе ваш менеджер может это обнаружить. Лучше не рискуйте.

1. Это все теория.
Аналогично теории эволюции или гравитации, это все просто теория.  Даже если вышеперечисленные причины не верны, то еще никто не доказал, что этот продукт мог быть сделан быстрее и с лучшим качеством, если бы использовались новые методологии разработки (например TDD). Это просто дело вкуса.

Проверьте себя.
Теперь для того, чтобы определить, нужно ли вам использовать TDD, пройдитесь по списку. Посчитайте сколько причин применимо к вам. Если вы насчитали 10 – ВАМ НЕ НУЖНО TDD. Если вы насчитали больше одного (например, п.8 может иметь право на жизнь), то не пишите вообще никакого кода. Возможно, вам нужно выбрать профессию, где мало неизвестных и движущихся частей. Может укладка асфальта?

Комментарии

  1. хахаха, вот так бред )))
    Только 10 пункт имеет право на жизнь - но это и ежу понятно. 9-ый - ну такой полубредовый. Остальные 8 - жесть и чушь несусветная.
    Спасибо, посмешили :)

    ОтветитьУдалить
  2. Спасибо за комментарий. Может и жесть, может и чушь - но большую часть "причин" я слышал в реальной жизни. Было бы смешно, если бы не было так грустно :)

    ОтветитьУдалить
  3. Смеялись всем офисом. Спасибо за 10 пунктов сарказма!

    ОтветитьУдалить
  4. Tatiana Shemyakina7 мая 2012 г., 11:17

     Это всё теория! XD Спасибо, улыбнуло.

    ОтветитьУдалить
  5. Alexander Petrovskiy9 ноября 2012 г., 03:30

    Исторически, в Аэлите, пост-Аэлите и клонах, п. 4 всегда имел право на жизнь :)
    Просто на 1300 инженеров 1500 сейлзов.

    ОтветитьУдалить

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после вчерашнего выступления.

Uncle Bob: "Flipping the Bit"

Подробнее постараюсь перевести чуть позже, пока только это:
Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :)
Мантра:

Сможете ли вы выполнить работу быстрее используя TDD? ДАСуществуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТЯ понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективеЧто если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДАВ любом случае? ДАЕсть ли случаи, когда вам не нужно использовать TDD? НЕТПредставьте себе что вы на звездном корабле Enterprise (Star track) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы использовать TDD? ДАПочему? П…