Итак, вот моя последняя запись: ловушка для стартапа ( вот его перевод — ок.
переводчик) наделал много шума.
Среди людей, выразивших согласие и поддержку, была и группа людей, категорически несогласных.
Я не буду перечислять здесь все разногласия, потому что в этом месяце я уже исчерпал свой лимит ругательств.
Но меня вдохновило одно альтернативное мнение и считаю необходимым его обсудить.
Речь идет о старом конфликте «прагматизм против догматизма».
Основная жалоба заключалась в том, что я был слишком догматичен.
Альтернативная точка зрения состоит в том, что в некоторых случаях TDD может быть оправданным, но в других TDD может быть слишком дорогостоящим.
Поэтому нужно быть прагматичным и выбирать мудро.
На первый взгляд эта идея звучит вполне разумно.
Ведь прагматизм – это хорошо, не так ли? Предположим, вы заранее знали, что если вы будете использовать TDD, вы пропустите срок, а если вы его не сделаете, то уложитесь в него, вы бы не стали использовать TDD, верно? Верно.
Нет вопросов.
И действительно, иногда бывает, что этот путь — правильный.
Цель этого поста — прояснить, когда я считаю, что TDD может оказаться слишком дорогостоящим.
Но прежде чем начать, я хотел бы отметить несколько моментов.
TDD — это дисциплина для программистов, точно так же, как двойная бухгалтерия — для бухгалтеров или стерилизация инструментов — для хирургов.
Бывают ли случаи, когда бухгалтеры не используют метод двойной записи? Бывают ли случаи, когда хирурги не стерилизуют инструменты? Ответ – да, в обоих случаях.
Я даже сомневаюсь, что бухгалтеры используют двойную запись при балансировании своих личных чековых книжек или при сверке суммы счета в ресторане.
Возможно, я ошибаюсь в отношении первого утверждения; в конце концов, я сам уже много лет использую метод двойной записи при балансировании своей чековой книжки.
Но постепенно я понял, что затраченные усилия не покрывают возможных рисков.
Что касается последнего примера, думаю, все согласятся, что для проверки счета в ресторане метод двойной записи явно излишен.
Теперь по поводу хирургов и процедуры стерилизации: пару лет назад мне удалили липому на ноге.
Моя жена наблюдала за этой процедурой.
Операция была проведена под местной анестезией в кабинете врача.
Я слышал, что моя жена спросила врача, почему он не провел процедуру стерилизации при подготовке к операции.
Он ответил, что для такой простой операции достаточно «процедуры очистки».
Нас с женой этот ответ удовлетворил, и врач провел операцию.
Через пару дней разрез воспалился и начал болеть.
Один из швов заразился, и врачам пришлось делать новый разрез и все там чистить.
Не знаю, была ли причина в «процедуре очистки», но с тех пор я настаиваю, чтобы лечащий меня врач проводил процедуру стерилизации, а не «процедуру очистки».
Однако утверждение остается верным.
Бывают случаи, когда TDD обходится слишком дорого и следует использовать более легкие дисциплины.
Я надеюсь, что моя история убедила вас в том, что такие случаи крайне редки и что мем о прагматизме не должен мешать вам применять свои дисциплины только потому, что они кажутся неуместными.
Прагматизм.
Итак, когда мне не следует использовать TDD?
- Я не пишу тесты для получения и установки свойств.
Обычно написание таких тестов — глупая практика.
Эти методы get и set будут проверены косвенно посредством тестирования других методов.
Поэтому тестирование get и set напрямую бессмысленно.
- Я не пишу тесты для переменных-членов.
Они также будут проверены косвенно.
- Я не пишу тесты для однострочных функций или для абсолютно тривиальных функций.
Опять же, они будут проверены косвенно.
- Я не пишу тесты GUI. Тестирование GUI — это хлопотно.
Что-то нужно переместить на место, изменив размер шрифта здесь, значение RGB там, координату XY там, ширину поля там.
Применять TDD таким образом глупо и расточительно.
- Однако я слежу за тем, чтобы любая значительная обработка была вынесена из кода графического интерфейса в тестируемые модули.
Я не позволяю важным фрагментам кода оставаться непроверенными.
Таким образом, мой код GUI — это не что иное, как просто связующее звено и провода, которые извлекают данные и отображают их на экране (см.
статьи о MVVM или MVP).
- В общем, я не пишу тесты для кода, с которым мне приходится возиться методом проб и ошибок.
Но я отделяю подобные «химические ковыряния» от кода, в котором уверен.
- Иногда я немного возлюсь с кодом, а затем пишу для него тесты.
- Кроме того, иногда я удаляю код, над которым уже поработал, и переписываю его заново в стиле TDD.
- Что делать в таких ситуациях – дело вкуса.
- Пару месяцев назад я написал программу длиной в 100 строк без каких-либо тестов (от удивления рты открылись!)
- Программа была разовой.
Его использовали один раз, а потом выбросили.
(Он был предназначен для создания спецэффекта в одном из моих видео).
- Программа длилась один экран.
По сути, это было чистое приложение с графическим интерфейсом.
Так что я просто собрал все, что мне нужно, в одном месте.
- Я написал его на Clojure и имел простую интерактивную среду программирования.
Я могу запускать растущую программу из этой простой интерактивной среды и видеть результаты каждой строки кода, которую я только что написал.
Это был не TDD, это была EDD (разработка, управляемая глазами).
- Обычно я не пишу тесты для фреймворков, баз данных, веб-серверов или другого стороннего программного обеспечения.
Я пишу для них моки и тестирую свой код, а не их.
- Конечно, иногда я тестирую сторонний код. Я проверяю, если:
- Такое ощущение, что он сломан
- Я получаю настолько быстрые и предсказуемые результаты, что написание макета было бы излишним.
Все это не догма.
Этот список не является полным.
Я уверен, что в другой раз подумаю, почему я иногда не пишу тесты, но суть списка должна быть ясна.
Прагматизм вступает в игру, когда вы практикуете TDD; это не догма.
Однако я уважаю догму.
Для этого есть причина.
Прагматизм иногда берет верх, но Я не буду писать какой-либо значительный фрагмент производственного кода, не приложив все усилия для применения TDD.
От переводчика: Марк Симэн уже прочитал эту статью дяди Боба и отреагировал своим , в которой он не согласен с некоторыми моментами и останавливается на них несколько подробнее.Теги: #tdd #разработка сайтов #программирование #tddКогда будет время, попробую перевести.
-
Черный Ящик Курильщика
19 Oct, 24 -
Baretail И Firephp
19 Oct, 24 -
Поисковик Quintura Выставили На Продажу
19 Oct, 24 -
21 Век Не Вписывается В Провода
19 Oct, 24
