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