За годы работы разработчиком я столкнулся с рядом проблем в продакшене из-за ошибок. Ошибки повсюду, и многие люди тратят часы и часы, пытаясь их исправить. Для меня это огромная проблема, потому что я люблю поспать, и я не могу спать спокойно, если у меня есть сомнения в качестве моего кода. По этой причине несколько лет назад я начал изучать, как хорошо спать, что сводилось к обучению тестированию моего кода.
Моим первым шагом в мире тестирования было выполнение тестов после написания кода. Это значительно улучшило качество моего кода. Однако это выявило другую проблему: на мои тесты влиял мой код. Чтобы избежать этого, я начал изучать TDD.
Когда мы делаем TDD, нашей отправной точкой являются некоторые сценарии/спецификации, написанные в виде тестов. После этого наше решение начинает разрабатываться до тех пор, пока мы не сможем убедиться, что наш код делает все возможное, чтобы соответствовать этим сценариям. Давайте рассмотрим пример простого проекта на JS.
Прежде всего, мы собираемся создать наш пример проекта, просто выполнив следующие команды:
mkdir tdd cd tdd npm init
Когда мы запустим npm init, терминал задаст нам несколько вопросов для создания нашего проекта. Как только мы ответим на них, просто запустите:
npm install --save-dev jest
Затем мы обновляем нашу тестовую команду в package.json до:
“test”: “jest”
После этого мы создадим два файла: calculate.js и calculate.test.js.
После этого, когда мы запустим npm run test, он завершится ошибкой и покажет такой результат:
Теперь мы можем написать правильный код, соответствующий этому сценарию:
JS — это не типизированный язык программирования, как известно разработчикам, поэтому любой может попробовать использовать наш метод, просто передав им строку, null, undefined… Мы могли бы создать больше тестов, чтобы проверить это, что создаст еще одну проблему: возможность повторного использования кода. и ремонтопригодность. Чтобы решить эту проблему, мы могли бы использовать подход к тестированию на основе данных. Это сделает наш процесс тестирования таким же простым, как добавление новой строки. Давайте изменим наш тест на подход к тестированию, управляемому данными.
Теперь мы можем добавить столько тестов, сколько захотим, просто добавив строку. Я добавлю несколько дополнительных строк для проверки различных пограничных случаев:
Как только мы запустим это, наш отчет будет следующим:
Наконец, мы меняем наш код, чтобы он работал правильно:
Со временем здесь, в Stubhub, мы смогли уменьшить количество (и серьезность) возникающих проблем. Мой код выглядит намного лучше (можете спросить у моих коллег :P), а отдел контроля качества больше не сварливый кот. Даже с этими действиями предстоит пройти долгий путь для улучшения качества нашего кода, и мы продолжим улучшать наш процесс, чтобы позаботиться об этом.
