О Ловушке Для Стартапов, Или Роберт Мартин Хочет Нам Навредить

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

Хотите знать, как я обычно ввязываюсь в подобные споры? - Так какие тесты ты пишешь сам? - Я-э-э.

- Когда ты пишешь тесты? - Я-э-э.

- Ты вообще тесты пишешь? - Я-э-э.

Ладно, я, конечно, пишу тесты, просто в таких спорах не участвую.

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

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

Но сейчас у меня, кажется, есть эта пара часов.

Классический TDD, тот, который говорит, что тесты «не должны ничего знать» о реализации, о реальном коде, мертв, поезд ушел, все кончено.

Но несомненно, его недолгое присутствие возымело ожидаемый эффект — все думали об уже написанном коде и думали о написании тестов для него, чтобы при изменении кода в будущем не возникало проблем.

Проблемы.

Это важно.

Проблемы.

Повторяю еще раз - Проблемы.

Если вы чувствуете себя некомфортно, давайте решим эти проблемы.

  • У вас много тестов, которые приходится удалять, если какая-то функция окажется ненужной? Ну и не пишите их так много — вы, скорее всего, экспериментируете с продуктом, и, возможно, подход «исследовать и стабилизировать» подойдет вам больше.

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

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

Прислушиваться к проблемам — единственный разумный способ разработки программного обеспечения.

Одна крайность – Роб Мартин – заведет вас в глубокие джунгли.

Другие – те, кто призывает вас вообще не думать об опасностях – скорее всего, приведут вас к неудаче.

Мысль о том, что тесты — это просто пустая трата времени, очень опасна, особенно если эта мысль укоренится в вашем сознании.

Но идея о том, что TDD абсолютно важен, не менее опасна.

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

Классический TDD — отличная теоретическая техника, с которой можно поиграть в свободное время или на выходных.

Classic TDD — отличный маркетинговый слоган, если вы один из тренеров или тренеров TDD. Да, TDD — это то, на что всегда обращают внимание при приеме на работу, но TDD обычно не является тем путем, по которому можно получить отличное приложение, доставленное вовремя.

Так какие же тесты вы вообще пишете?

  • Обычно я использую подход «исследовать и стабилизировать» для функций, которые в конечном итоге могут быть исключены из конечного продукта.

    Таким образом я не трачу время на тестирование раньше, чем это необходимо, и получаю отзывы о новых функциях максимально быстро.

  • Обычно я начинаю с интеграционных тестов, заменяя все медленные части их представлениями, основанными на памяти (например, заменяя в тестах БД на БД в памяти).

  • Я спускаюсь на уровень модульного тестирования, если вижу сложную логику (как ни странно, большинство систем — обычные CRUD, так что в этом нет необходимости)
  • Варианты использования обычно тестируются с использованием пользовательского интерфейса в рамках приемочных тестов, поскольку именно это видит пользователь.

Общий Когда дело доходит до тестирования, есть два типа прагматиков.

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

От переводчика: Роб Эштон — известный разработчик-фрилансер из Европы, участвовавший во многих проектах с открытым исходным кодом.

Теги: #правильное программирование #профессионализм #чистый код #tdd #тесты #рефакторинг #разработка сайтов #программирование #Идеальный код
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.