Только боюсь, что дороги после этого лучше не станут. При чем тут дороги? Читаем дальше J
Вы можете забыть о практике TDD, не писать автоматические тесты, если:
10. У вас нет клиентов.
Иногда вы делаете продукт, который никем не используется. В этом случае любые затраты на качество – это напрасные затраты.
9. Если вашему клиенту нравится тестировать самостоятельно.
Некоторым людям большего все на свете нравится участвовать в бета-программе. Получить удовольствие от свеженайденной баги и попытаться понять, почему она произошла – это то, ради чего они живут. Другие чувствуют себя учеными в душе и любят поковыряться с стек-трейсах для реверс-инжинирига. Если ваш клиент один из них – то ваши автотесты лишат их удовольствия от использования вашего продукта. Не делайте этого!
8. Ваш проект короткий, простой и понятный.
Если ваша команда может закончить проект за короткий период времени (не больше нескольких недель) и не будет никогда его поддерживать, то все преимущества типа возможности повторного использования, эксплуатационной надежности и расширяемости будут потеряны для вас. Тратить время на эти вещи бесполезно.
7. Ваша архитектура безупречна.
Если больше нет способов улучшить архитектуру вашего проекта, то вам не нужно, чтобы она была расширяемой. TDD – это инкрементальная разработка, она заставляет архитектуру быть расширяемой. Если у вас все в порядке с архитектурой, то TDD вам нужен, как губная помада свинюшке J
6. У вас отличная документация.
Вы никогда не забываете API, все изменения в вашем продукте постоянно документируются. Если ваша документация настолько полная, то написание тестов противоречит принципу DRY (don’t repeat yourself), потому что правильно названные и написанные тесты показывают вам все, что нужно для понимания Тесты будут дублировать документацию, поэтому не пишете тесты.
5. Ваша команда не меняется и у всех отличная память.
Коллективная память никогда не забывает ни одной написанной строчки, а также причины ее появления. Поэтому вам не нужны тесты для запоминания того, что код делает, почему он это делает и как его использовать. Это также означает, что никто в команде не покидает ее, новых людей вы не нанимаете, потому что иначе вы теряете эту память и у вас появляются люди, которые не «помнят» код. Просто их не было, когда код писался. Если все так и есть, то тесты только мешают вашей невероятной производительности.
4. «Сделано» означает, что код зачекинен.
Многие команды считают, что «сделано» определяет момент, когда фича доходит до пользователя (она закодирована, проверена, развернута, документирована и тд). Многие другие, в том числе и ваша команда, предпочитают более простое и легко достижимое определение, где «зачекинено» означает «сделано». Для вас достаточно того, что разработчик сказал, что он закончил свою часть. Все остальное – это обязанности кого-то другого.
3. Вам платят за код, а не за тесты.
Игнорируя тот факт, что модульное тесты это код, тестирование – это то, для чего у нас есть тестировщики. Возможно, ваша команда тестирования очень шустрая, она может тестировать ваш код и давать вам фидбек мгновенно, с указанием того места, где вы поломали код. В этом случае, у вас есть возможность чинить это, пока изменения свежи в вашей памяти. Если ваши тестировщики работают также хорошо как регрессионная тестовая сюита, то берегите их и заботьтесь о том, чтобы у них было много работы. Иначе они будут скучать и уйдут от вас в другую компанию, где им скучать не дадут.
2. Отладка не считается, а тестирование занимает много времени.
Вам нужно оценивать сроки, сколько времени уйдет на выпуск продукта. Так как ваше «сделано» не учитывает тестирование, а также вы не можете оценить, сколько времени уйдет на отладку, то вы оцениваете только то, сколько вам понадобиться времени закодировать это. Если вы хотите выдержать сроки, то вам нельзя накинуть 20% сверху (на всякий случай), иначе ваш менеджер может это обнаружить. Лучше не рискуйте.
1. Это все теория.
Аналогично теории эволюции или гравитации, это все просто теория. Даже если вышеперечисленные причины не верны, то еще никто не доказал, что этот продукт мог быть сделан быстрее и с лучшим качеством, если бы использовались новые методологии разработки (например TDD). Это просто дело вкуса.
Проверьте себя.
Теперь для того, чтобы определить, нужно ли вам использовать TDD, пройдитесь по списку. Посчитайте сколько причин применимо к вам. Если вы насчитали 10 – ВАМ НЕ НУЖНО TDD. Если вы насчитали больше одного (например, п.8 может иметь право на жизнь), то не пишите вообще никакого кода. Возможно, вам нужно выбрать профессию, где мало неизвестных и движущихся частей. Может укладка асфальта?
хахаха, вот так бред )))
ОтветитьУдалитьТолько 10 пункт имеет право на жизнь - но это и ежу понятно. 9-ый - ну такой полубредовый. Остальные 8 - жесть и чушь несусветная.
Спасибо, посмешили :)
Спасибо за комментарий. Может и жесть, может и чушь - но большую часть "причин" я слышал в реальной жизни. Было бы смешно, если бы не было так грустно :)
ОтветитьУдалитьСмеялись всем офисом. Спасибо за 10 пунктов сарказма!
ОтветитьУдалитьЭто всё теория! XD Спасибо, улыбнуло.
ОтветитьУдалитьИсторически, в Аэлите, пост-Аэлите и клонах, п. 4 всегда имел право на жизнь :)
ОтветитьУдалитьПросто на 1300 инженеров 1500 сейлзов.