Разработка через тестирование - это процесс разработки программного обеспечения, который требует от программиста написания тестовых примеров для каждой функции программного обеспечения перед ее написанием.

В этой статье мы будем использовать программное обеспечение для управления отпуском, созданное мной для объяснения разработки через тестирование (TDD). Мы будем использовать среду тестирования JavaScript под названием Jest. Сначала я объясню кое-что о TDD.

Почему именно TDD?

До того, как я научился создавать программное обеспечение с помощью разработки через тестирование, у меня, как у начинающего программиста, был свой собственный цикл разработки. Я бы написал функцию, которая должна что-то делать, запустить ее с параметрами образца на консоли моего браузера и посмотреть, дает ли она правильный результат. Если результат неправильный, я редактирую свой код и запускаю его снова. Я продолжаю делать это, пока не получу требуемый результат. Этот процесс называется ручным тестированием, и именно так многие программисты разрабатывают программное обеспечение. Откровенно говоря, это очень неэффективный способ разработки программного обеспечения, поскольку он требует много времени, и вы, скорее всего, в конечном итоге напишете избыточные коды (ненужные коды). Помните, «важно экономить время, место и, конечно же, энергию».

TDD имеет собственный цикл внедрения, и да, он экономит время, пространство и энергию. Ниже приводится краткое описание цикла TDD.

Цикл TDD

  1. Напишите тестовый пример для функции.
  2. Запустите свой тест, чтобы убедиться, что он не работает.
  3. Напишите код для прохождения теста (не пишите то, что вам не нужно).
  4. Запустите тест, чтобы убедиться, что он проходит.
  5. Выполните рефакторинг вашего кода и убедитесь, что все предыдущие тестовые примеры по-прежнему проходят.
  6. Повторяйте, пока не получите все функции программного обеспечения.

6 шагов, описанных выше, обобщены в популярной мантре TDD:

«Красный → Зеленый → Рефакторинг»

Настройка IDE для тестирования

  1. Диспетчер пакетов узлов (npm) или пряжа
  2. Фреймворк Jest
  3. Два файла - один файл .js для кода разработки, один файл .test.js для написания теста (например, index.js и index.test.js).

Вышеуказанная настройка - это то, что я использовал для программного обеспечения для управления отпусками. Для более крупного проекта вам, возможно, придется сгруппировать файлы по подпапкам. Чтобы запустить установку, откройте вашу рабочую папку в терминале и выполните следующие действия;

// to initialise npm (assuming you've installed node)
npm init
// to install the jest framework
npm install --save-dev jest

В файле package.json, созданном с помощью npm init, найдите свойство «scripts» и отредактируйте его, указав приведенные ниже сведения. Покрытие кода поможет нам проверить процентную долю нашего кода, который был протестирован.

"scripts": {
"test": "jest --coverage"
}

Как провести тест

Если вы хотите протестировать свой рабочий каталог (содержащий несколько тестовых файлов), просто введите ‘npm test’ в своем терминале. Чтобы запустить единый набор тестов, введите ‘npm test suite-name’.

// by working directory
npm test
//by test suite
npm test <name-of-test-suite>

Определение терминов

Набор тестов - тестовый файл, содержащий тестовые примеры для ваших методов. Он назван по имени файла, содержащего ваши методы. Если вы назовете файл index.js, назовите набор тестов index.test.js.

Тестовый пример - функция, содержащая набор условий, при которых методы будут проверяться на правильность их работы.

Сопоставление - используется в тестовом примере для сравнения двух значений и возвращает результат "успешно", если сравнение верно. В его левой части находится ожидаемое значение, а в правой части - значение, которое нужно сравнить. Например, «toBe», «toEqual», «toContain», «toHaveProperty».

Без определения метода, который мы хотим протестировать, набор тестов не запустится. Если мы напишем метод без тела, набор тестов будет запущен, но тестовый пример для этого метода завершится ошибкой. Если у нас есть метод, который возвращает неправильное значение, набор тестов будет запущен, но тестовый пример завершится ошибкой.

Реализация

Наша система управления отпусками отслеживает сведения о сотрудниках и их историю запросов на отпуск, а также дает администратору возможность утвердить или отклонить запрос на отпуск. Перейдите по этой ссылке на репозиторий GitHub.

В системе есть методы для выполнения некоторых операций, в том числе следующие:

  • Запрос на отпуск
  • Прочитать запросы на отпуск
  • Утвердить заявку на отпуск
  • Отклонить запрос на отпуск

В этой статье мы увидим, как проверить работоспособность некоторых методов.

В нашем файле разработки мы объявили и определили «объект базы данных», «конструктор персонала», «конструктор администратора» и «конструктор запроса на отпуск». Мы также написали метод «сохранения новых пользователей», который был протестирован. В приведенном ниже фрагменте в строках с 42 по 44 показано, как экспортировать необходимые переменные, чтобы они были доступны в нашем тестовом файле.

Ниже представлена ​​настройка нашего тестового файла.

  1. Отправка запроса на отпуск

Теперь нам нужна функция, которая позволит сотрудникам отправлять запросы на отпуск, и мы хотим, чтобы параметрами были «продолжительность» и «тип отпуска». Итак, мы записываем тестовый пример в наш тестовый файл.

Примечание. Обычно я пишу комментарии о том, чего я хочу достичь с помощью своих тестовых примеров, и беру комментарии один за другим. Это просто способ направить мои мысли, после этого я удаляю все ненужные комментарии.

Приведенный выше набор тестов не запустится, потому что мы не определили метод makeRequest. Блок «описать» используется для объяснения функциональности теста. Переменная 'result' содержит ожидаемое значение того, что было возвращено с левой стороны оператора присваивания '=' (этот шаг на самом деле не нужен, вы можете удалить строку 8 и заменить result в строках 9 и 10 с database.request [0]). Таким образом можно написать любой нужный нам тестовый пример. В строках 9 и 10 мы используем сопоставители для сравнения результата (нашего ожидания) с тем, что находится в базе данных. и посмотрите, совпадают ли они.

Сопоставитель toHaveProperty используется для проверки наличия у объекта определенного свойства, и мы указываем ключ и значение собственности.

Следующим шагом является переход к файлу разработки и определение метода. Мы снова запускаем тест и переписываем наш код, пока этот тест не пройдет. Если вы считаете, что написали тест неправильно, можно его также переписать.

2. Чтение всех запросов на отпуск

Напомним, что некоторые методы доступны только для административных объектов, поэтому мы будем использовать администратора, а не персонал для тестирования метода. Сопоставитель toBe, используется для строгого сравнения (точно так же, как строгое равенство в javascript ===). Для более гибкого сравнения используйте toEqual.

Запустите тест и посмотрите, как он не работает. Затем перейдите в папку разработки и напишите метод для этой функции. Запустите тест еще раз и отредактируйте код, если он не прошел. Если ваш код / ​​тест повлиял на предыдущие тестовые примеры, вам необходимо повторить свои действия и провести рефакторинг кода.

3. Утвердить запрос на отпуск

Опять же, этот метод открыт только для администратора. Блок описания ниже показывает, что у нас есть два тестовых примера для этого метода. Это потому, что у метода есть условие (оператор if). Итак, сначала мы пишем тестовый пример, когда условие истинно, запускаем цикл тестирования. Во-вторых, мы пишем тестовый пример, когда условие ложно, и повторяем цикл тестирования.

Написание метода…

Метод отклонения запроса на отпуск аналогичен этому. Единственная разница в том, что новое свойство isApproved будет иметь значение false.

Заключение

Вы можете подумать, что в тестировании нет необходимости, особенно если вы уже знаете, чем хотите заниматься, или когда чувствуете, что время тратится зря. Могу вас заверить, что в конечном итоге это сэкономит ваше время и облегчит рефакторинг. Просто нужно к этому привыкнуть. TDD также позволяет легко сохранять ваш код СУХИМ. Это ускоряет отладку, поскольку вы знаете, что ожидается от каждого теста, и можете легко проверить, почему ваш код не работает должным образом.

Для получения дополнительной информации о том, как использовать Jest framework, особенно сопоставители, прочтите Документацию Jest.

Для получения подробной информации о тестировании и построении системы управления выходом перейдите по этой ссылке в репозиторий GitHub. Если вам понравилась эта статья, похвалите меня, щелкнув значок хлопка ниже. Я также очень уверен, что вам понравится моя статья о прототипах и объектно-ориентированном программировании на JavaScript с использованием той же системы управления отпуском, которая расположена здесь.