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

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.  Это всё теория! XD Спасибо, улыбнуло.

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

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

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

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.