Проблема с Test-Driven Development

Проблема с Test-Driven Development

Chris Fox

На самом деле всё элементарно.

Я делаю предварительный дизайн больше, чем кто-либо из моих знакомых; как фрилансер я откажусь от клиента, который хочет, чтобы я работал без спецификации. Во многих компаниях я написал первый проектный документ в их истории, и не все из них были стартапами.

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

Так что написание тестов до кода, основа TDD, гарантирует, что я буду постоянно пересматривать тесты, чтобы интегрировать открытия, которые я сделал в кодинге.

Хорошо, это неэффективно. Это не катастрофа, но просто еще один случай, когда вы сделали явно неправильный выбор. Ничего необычного в нашей отрасли.

Но что мне действительно не нравится в TDD, так это интенсивность фанатизма вокруг него. Утверждения, которые я видел:

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

Я разработчик с конца 80-х, я знаю, что видел... Современные молодые разработчики так и не научились концентрироваться, и если они могут, то их выбивают из-за постоянных перерывов, в основном бессмысленных повторяющихся встреч. Люди, которые не могут сосредоточиться, пишут дерьмовый код с множеством ошибок, неудивительно, что они думают, что тестирование так важно.

Причина TDD основана на лжи и мифах:

  • метрики его ценности основаны на сравнении с отсутствием тестирования, а не на сравнении с традиционным тестированием черного ящика.
  • есть ложь, что до TDD мы вообще не тестировали. Это фигня. Те, кто передавал свою работу QA, чтобы они нашли баги за 10 минут - выглядели неловко. Мы тестили очень много.

Для моих денег TDD - это просто еще одна глупая причуда, такая как agile и scrum, хотя и не столь разрушительная, как Xtreme, которая отправляет людей в терапию или даже в больницы, и это одна из тех программных причуд, где стандартная практика меняется на противоположную. Вверх тормашками в том, что должно быть своего рода авансом. Что, черт возьми, было причиной (этого) дерьма?

Но худшая часть TDD - это ожидание, что разработчики будут нести в первую очередь, если не единоличную, ответственность за тестирование своей собственной работы. Как будто они будут думать о случаях в тестах, которые упустили в коде. Это просто потрясающая глупая идея.


Переведено командой QApedia. Еще больше переведенных статей вы найдете 

на нашем телеграм-канале.

Report Page