«Разработка через тестирование (TDD) — это способ управления страхом во время программирования», — Кент Бек.

Введение

TDD, что означает разработка через тестирование, — это способ создания программных приложений. Такой подход усложняет процесс. Разработчику приходится писать дополнительный код — тест-кейсы. TDD гарантирует, что часть кода выполняет требуемую задачу перед выпуском. Это гарантирует, что код может быть легко изменен, поскольку бизнес-требования имеют тенденцию меняться. Процесс состоит из трех основных этапов: написание неудачных тестов, написание кода, удовлетворяющего требованиям тестов, и рефакторинг.

Перед началом

  • Код приложения должен соответствовать определенным стандартам, после чего его можно протестировать.
  • Приложение использует архитектуру MVC.
  • Этот учебник посвящен только тестированию контроллеров [бизнес-логики].

Настройка среды

mkdir todo-api
npm init -y

Установить зависимости

Зависимости:

npm i -S express body-parser mysql2 sequelize morgan
npm i -D chai mocha nodemon sinon

Структура файла

Файловая структура типичного приложения Node.js MVC выглядит следующим образом:

Тестовые файлы для контроллеров находятся в папке контроллеров и имеют префикс .spec.js. Это всего лишь личные предпочтения.

Тестовая команда

Команда test находится внутри файла package.json как:

“test”: “mocha controllers/*.spec.js”

Написание непройденного теста

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

Требование Документ

Todo — это простой текст, который информирует о работе, которую необходимо выполнить. Приложение Todo позволяет пользователю создавать задачи и выводить список всех задач.

В соответствии с требованием должно быть два API — создать задачи и список задач.

Тестовые случаи

Вот список тестовых случаев:

Теперь, если запущена команда npm test, mocha показывает ниже. Есть пять ожидающих проверки без пройденных или непройденных тестов.

  • Импортируйте chai, sinon и todoController.
  • Восстанавливайте синон согласно их документации после каждого теста.
  • Перед каждым тестом объявляйте req, res и next, используя подделку или заглушку. Они нужны для отправки в качестве аргументов контроллерам.

Еще ничего не сделано. Итак, первый тест написан следующим образом для первого случая текст должен быть предоставлен. Тест проверяет, не указан ли текст в теле запроса, он должен вызвать ошибку и передать управление следующему middleware (подробнее см. код внутри app.js, который обрабатывает ошибки ).

Функция обратного вызова, переданная в тест, является асинхронной, поскольку внутри createTodo есть вызывающие промисы (асинхронный код). Теперь давайте запустим тест и посмотрим на результат:

Написание кода, удовлетворяющего тестам

Функция createTodo внутри контроллера todo должна удовлетворять требованиям теста. Функция контроллера проверяет, не предоставлен ли текст, и передает управление следующему промежуточному программному обеспечению с передачей ошибки.

Теперь тест проходит:

Рефакторинг

По поводу рефакторинга много дискуссий и выступлений. На этом этапе разработчик рефакторит код. Также можно использовать парное программирование.

Повторение

Шаги повторяются для каждого теста.

Вывод

Разработка через тестирование упрощает жизнь программиста, но требует дополнительных усилий.

Я ценю ваши комментарии и отзывы.

Репозиторий можно клонировать здесь.