Как и почему я решил, что тестовая разработка стоит моего времени

kak i pochemu ya reshil chto testovaya razrabotka stoit moego?v=1656620605

автор Ронаули Сильва

Впервые я прочитал о тест-управляемой разработке (TDD) в блоге некоторых технических обзоров, но я едва ли прочесть (или подумать). Зачем людям сначала писать тесты когда они уже знали логику?

О чем это все было? Сначала писать тесты, постепенно перестраивая логику и выполнять это на итерациях. Самое смешное то, что когда вы даете двум программистам пять минут, чтобы закодировать простую последовательность Фибоначчи, и просите одного сделать TDD, к концу 5 минут программист, выполняющий TDD, может сказать: «У меня есть тест на это!» Но они не закончат код. Кроме того, другой закончит всю последовательность Фибоначчи и оптимизирует ее.

Зачем использовать TDD? Разве модульные тесты недостаточно хороши?

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

Почему мы должны сначала писать тесты, когда я могу напрямую кодировать логику, спросил мой мозг? Разве мы не можем написать их позже? После завершения всех функций?

1*G2pGmoV1UXUH1izsziJDSw
Как это выглядит, когда наш наставник TDD убедит нас

Позвольте кратко предоставить вам краткий обзор TDD.

Скажем, я создаю функцию Фибоначчи. Я могу спросить, что такое самый простой утверждение о Фибоначче?
=> Возвращает 1, если вход равен 1.

1*uXMbt9iEYwdXCIt7ii6Zkg
Сначала написать тест без логики!

Что самое простое решение за это утверждение? The самое простое решение, Я имел это в виду.

1*qajwrX_pTW-3LDFxY_BafQ

Теперь следующий шаг. Каково следующее самое простое утверждение для Фибоначчи?
=> Возвращает 2 для входов = 3

1*vKLIf8aqUSaylG2UZvP9Zg

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

1*zU1Q78Q9v3SD6LVycIrYfQ

Выделите другое ожидание. Стремитесь к большему количеству. Делайте это итерационно, постепенно.

1*vANcpoacacpjY-HbkpEIZA

Так продолжается и продолжается, пока вы не получите хорошее решение для вашей функции Фибоначчи. Если вы хотите больше потренироваться, попробуйте добавить запоминание во время процесса (и не забывайте – с помощью TDD).

Вы заметили, что мы там делали? Детские шаги, ваше утверждение и как мы определяем решение? Ваш процесс мышления разделился на эти пять критических точек:

Простой и инкрементальный дизайн. Вы должны думать о том, что самое простое может сделать конкретная функция и что будет дальше. Пример Фибоначчи отлично описывает эту точку.

утверждение Каковы ваши ожидания от этой функции? И как вы охарактеризуете это ожидание? Быстро ли это поймут другие люди?
Некоторые библиотеки тестов предоставляют вам описание теста. Эта строка – это единственная подробная вещь, объясняющая, что делает ваш код.

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

1*B7_rBZ57kOtz92rrsWW-KA
Ваше утверждение и то, как вы его выражаете, имеют значение.

Проверенный дизайн — Как его спроектировать, чтобы его можно было проверить? Посмотрите на эти два фрагмента ниже.

Первый:

1*VYWzFZjaMaZj1EEBZ-TKPg
Посмотрите, как это бессвязно, если ваш код нельзя проверить.

Выполняя TDD, поскольку вы сначала пишете тест, вы должны убедиться, что ваш код есть подлежит проверке. На примере видно, что вы даже не проверяете свою функцию Фибоначчи. Вместо этого вы тестируете посторонний эффект этой логики фибоначчи в вашем коде, которая вызывает функцию console.log.

Другое дело, что вы никогда не знаете, какой из них не работает, console.log() или ваш блок фибоначчи, когда вы его рефакторируете. Таким образом, TDD приводит нас к увеличению модульности нашего кода.

Теперь давайте посмотрим второй фрагмент.

1*I2U7QrcmisWipCcYd_pcUQ

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

Негативы и угловые дела — чего вы ожидаете, когда что-то не так: это вызывается из null? Создаёт ли исключение? Как с этим обращаться? Что может произойти в коде? Что может быть самым удивительным и удивительным, что может произойти в этом цикле? Какой тест может это обнаружить?

1*M1cysq3GcCAVSGTSyCT1Bg
Сколько возможностей?

Границы — Следует ли ожидать этого от своей функции? Вы уверены, что это не ответственность другого класса?

0*o6kKa-ib3wswzKqe

Мои проблемы с TDD

Да, это действительно медленно. Иногда ваше время удваивается, поскольку вы пишете и тесты, и логику одновременно. Это делает важным то, как вы используете клавиатуру (скорость ввода, лучшее использование ярлыков и т.п.).

И что еще хуже – когда требования меняются – вам придется переделать или удалить и переписать тестовый код, над которым вы упорно работали. Это означает, что тестовый код – это написанный вами код, который, скорее всего, будет удален в будущем. И вы делаете это итерационно. УДАЛЯЕТ. КОДЫ. ПЕРЕПИСАЕТ. Снова. В ПЕТЛЕ!

Подумай об этом. Зачем вам писать код, который скорее всего будет удален?

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

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

Почему я передумал

Просветление наступило примерно через два месяца, когда меня назначили в группу, совсем плохо внедрявшую TDD.

Я имею в виду, они внедрили TDD, но они оставили тесты сломанными. Они не потрудились исправить те неудачные тестовые случаи (которые часто ломались из-за изменений требований). И это произошло по самой банальной причине в мире: они не успели. Они должны были задать сроки.

Осмотрев ситуацию, я пробормотал: «Смотри, видишь! Этот TDD не работает в производственном мире! Это заставило меня спросить многое: стоит ли за этот TDD бороться? Стоит ли TDD затраченного времени? Приносит ли это какую-то ценность для бизнеса?

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

Вот некоторые из проблем, которые это вызвало:

  • Когда я добавил новую функцию или переделал вещи, я не знал, работает ли этот код, потому что тест уже провалился.
1*qL_hflKv-kH7IOjxfnqQqg
Мы не знаем, на каких тестах я провалился, потому что почти все они уже провалились раньше! -_-
  • Мы были вынуждены установить высокий порог покрытия кода. И не ошибайтесь, программисты умны и подлый. Они пишут тесты без ожиданий, как тесты на дым. И это было то только тест, который они имели в этой конкретной логике. Было так, что мы знали, что он выходит из строя только после того, как все горело. Как небезопасно.
1*Gq_uwGye0DYRcXA822w1fA
Всегда мимоходом! Покрытие всех кодов града!
  • Мы использовали CI/CD для развертывания. И мы всегда разворачивали, даже если это было неудачно, что было страшно: вы никогда не знали, дает ли сбой именно ваше производство, или это было потому, что вы не исправили тесты.
1*g_0sJ3rQKpauqi3wuLzD0g
Тест не прошел, все равно разверните!
0*8R6C2z00Z6f7F7fC
  • После производства мы в конечном счете исправили странные и совершенно бессознательные ошибки. Раньше мы даже не думали об этих странных условиях. (Вы когда-нибудь находили ситуацию, когда что-то в блоке try-catch выходит из строя, но не создает исключение?)

Ужас!

Проанализировав ситуацию, сделав это по итерациям и поразмыслив над этим, я понял, что TDD на самом деле является золотым самородком. Если все сделано правильно, то это может сделать нас лучшими разработчиками.

Почему я сейчас люблю TDD

С TDD у вас меньше ошибок

Вы вряд ли пропустите вещи, которые вы можете поймать с помощью тестов.

Когда вы получаете требование, вы сначала пишете для нее тест. Затем вы запускаете тест и сначала проверяете, не завершился ли он. Когда вы добавляете логику, вы видите, проходит ли она.

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

TDD экономит вам много времени (в будущем)

CI/CD во многом полагается на тесты. Если вы пишете неправильные тесты (или слишком мало тестов), вы уже потратили пять часов, чтобы найти какие ошибки он не смог уловить. Если вы пишете хорошие тесты и потратите всего пять минут на написание более глубоких и более полных условий своего кода, вы сэкономите время на его отладку в будущем.

TDD занимается человеческими аспектами кодирования

Основные из них – небрежность и забывчивость. Если вы напишете всю логику напрямую, до конца, скажем, строки 190, вы можете забыть, почему вы умножили переменную на 100 в строке 19.

Но делая это постепенно и констатируя утверждение нашего кода, мы постепенно строим наше понимание. Благодаря этому мы лучше осознаем код и его поведение.

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

TDD помогает сосредоточиться

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

TDD также приносит пользу вашему мозгу

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

0*m9IeLR30F2AAtlwu

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован.