«Разработка через тестирование (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 должна удовлетворять требованиям теста. Функция контроллера проверяет, не предоставлен ли текст, и передает управление следующему промежуточному программному обеспечению с передачей ошибки.
Теперь тест проходит:
Рефакторинг
По поводу рефакторинга много дискуссий и выступлений. На этом этапе разработчик рефакторит код. Также можно использовать парное программирование.
Повторение
Шаги повторяются для каждого теста.
Вывод
Разработка через тестирование упрощает жизнь программиста, но требует дополнительных усилий.
Я ценю ваши комментарии и отзывы.
Репозиторий можно клонировать здесь.