Это мой первый пост из серии, посвященной TDD (разработка через тестирование). Я собираюсь рассказать о некоторых основах того, что это такое, о преимуществах, некоторых типах тестов, которые он использует, и о структуре Jest, которую вы можете использовать для его реализации. Тестирование — ценный навык для любого программиста, позволяющий создавать более надежные приложения. В будущих постах я сосредоточусь на том, как писать каждый тип тестов, составляющих TDD.
Так что же такое ТДД?
TDD – это итеративный подход. Как, скажем, живой организм развивается и приспосабливается к окружающей среде, так же и код — развивается и приспосабливается к своим испытаниям. (Арек Торчук)
TDD — это методология, которая включает в себя написание тестов, которые терпят неудачу, до разработки, а затем написание нового кода, чтобы эти тесты прошли. Каждый тест определяет и описывает, что будет делать этот код. Если бы явно следовал TDD, вы бы делали это для каждой небольшой функции в вашей программе, пока не было бы 100% покрытие (высокая цель)! Однако основная цель состоит в том, чтобы убедиться, что все работает должным образом, включая все входные данные и сценарии. Программисты пытаются использовать как можно меньше кода для достижения ожидаемого результата, а затем возвращаются к рефакторингу для элегантности и спецификации командного дизайна. Это отличается от традиционного подхода, когда вы пишете код, проверяете, работает ли он, а затем проводите рефакторинг. Эта диаграмма иллюстрирует основной процесс TDD:
Зачем нужен TDD и в чем его преимущества?
Давайте будем честными, код беспорядочный. Недавно я услышал, что базовый код для одного автомобиля Tesla составляет более 600 миллионов строк. По мере того, как программы становятся больше, а код взаимодействует все более сложным образом, вероятны ошибки. Функции становятся взаимозависимыми, и ошибки могут возникать в областях, далеких от того, где вы на самом деле работаете! В конечном итоге цель TDD — сделать код проще и без ошибок.
Сторонники TDD сообщают о следующих преимуществах:
- Несмотря на то, что поначалу требуется много времени, TDD в конечном итоге сокращает затраты на разработку. Здоровая кодовая база должна поддерживаться постоянно, и с помощью тестов вы можете быть уверены, что ваши функции не сломаются. Все еще проходит? Вы можете идти! Если это не так, у вас будут ресурсы и информация, чтобы отследить ошибку.
- TDD способствует осознанному принятию решений, потому что заставляет вас думать о том, чего вы пытаетесь достичь, прежде чем приступить к реализации. Больше никаких взломов пути к решению!
- TDD создает SOLID код. Более простой код легче тестировать, что вынуждает программистов создавать более элегантные решения, соответствующие принципу единой ответственности.
- Модульные тесты создаются с описаниями, понятными даже нетехническим людям. Они могут служить документацией для самого кода.
- TDD поддерживает долгосрочную масштабируемость и основные изменения в архитектуре. Без тестов инженерам приходится вносить изменения без настоящей интеграции, что приводит к проблемам в дальнейшем.
- TDD предотвращает расползание области, имея четкие цели и определенные требования. Больше не нужно добавлять «золотое покрытие» или функции, которые не соответствуют первоначальной цели программы.
В заключение я хотел бы сказать, что, хотя широко распространено мнение, что TDD в целом снижает затраты и время на разработку, растет число программистов, которые выступают против его преимуществ. На мой взгляд, это все же лучший подход к предотвращению ошибок, чтобы ваш клиент их не обнаружил.
Типы тестов
Модульные тесты
Модульные тесты — это хлеб с маслом в мире тестирования! Они нацелены на тестирование полностью изолированного фрагмента кода, такого как функция, путем предоставления входных данных и проверки ожидаемого результата. Их проще всего написать, и они должны составлять большую часть вашего набора тестов.
Интеграционные тесты
Интеграционные тесты имеют дело с зависимостями, например, когда функция вызывает другую функцию. Все ваши модульные тесты могут работать, но ваша программа дает сбой, потому что они не работают вместе должным образом. Чем больше зависимостей или обращений к серверу, тем сложнее писать. Умение работать с ними сделает вас очень ценным специалистом по обеспечению качества!
Сквозные тесты
E2E-тесты (также известные как функциональные тесты, тесты приложений, полнопотоковые тесты или тесты пользовательского интерфейса) являются наиболее сложными и наименее распространенными из тестов. Они предназначены для имитации взаимодействия пользователя с виртуальным браузером, который ожидает результатов, не заглядывая во внутренний код.
Фреймворк Jest
Нет недостатка в тестовых средах для каждого языка и типа теста. Виталий Зайдман сделал очень подробный пост о возможностях JavaScript в 2019 году здесь. Рекомендую посмотреть, если есть время! Чтобы настроить ваше приложение для тестирования, вам понадобится бегун, который выполняет тесты. Во-вторых, вам понадобится библиотека утверждений для определения ваших тестов и логики. Существуют пакеты, которые заботятся об этом по отдельности (Mocha и Chai), но Jest становится повсеместным и выполняет оба этих шага в одной программе. Это отличный выбор для начала работы, и он быстро работает на больших платформах. Одна из целей создателя заключалась в том, чтобы он был без конфигурации, чтобы он был готов к использованию прямо из коробки!
Jest распространяется через диспетчер пакетов узла, поэтому давайте установим его в проекте.
Затем создайте файл с именем util.test.js — Jest просматривает все файлы со словом test в имени. Затем перейдите в файл package.json и настройте файл сценариев следующим образом:
"scripts": {
"test": "jest"
},
Теперь Jest готов к работе! После написания тестов все, что нам нужно сделать, это набрать: «пошутить — посмотреть», и он автоматически запустится. Виола! В следующем посте я расскажу о модульных тестах, строительном блоке TDD!