Это мой первый пост из серии, посвященной 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!