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

Введение

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

Основные причины TDD

Ниже приведены несколько причин, почему TDD важен:

  • Это позволяет избежать чрезмерной инженерии.
  • Это помогает предотвратить ошибки.
  • Это помогает сократить затраты на разработку в долгосрочной перспективе.
  • Он создает поддерживаемую кодовую базу.
  • Он поддерживает отличную документацию.

Как работает TDD

Чтобы практиковать TDD, необходимо выполнить следующие шаги:

  1. Начните с написания теста.
  2. Запустите тест. На этом этапе тест должен провалиться, так как кода еще нет.
  3. Затем напишите минимальный объем кода, чтобы пройти вышеуказанный тест.
  4. Запустите тест еще раз, чтобы увидеть, пройдет ли он на этот раз.
  5. Рефакторинг вашего кода, если это необходимо.
  6. Повторяйте с step1, пока не закончите разработку.

Тестирование в Javascript

Существует множество способов тестирования кода javascript. Поскольку TDD предназначен для написания автоматизированных тестов, уже есть доступные фреймворки, которые мы можем использовать для достижения этой цели. Некоторые из них QUnit, Mocha, Tape, AVA, Jasmine, Karma и Jest.

Для иллюстрации мы будем использовать Jest в качестве нашей основы. Jest — один из самых популярных фреймворков, который Facebook регулярно поддерживает. Он подходит из-за своей нулевой конфигурации.

Мы будем использовать методы и функции Simple Auction System, которые мы использовали в этой статье Прототип-ориентированное программирование, для объяснения TDD. Вы можете ознакомиться с проектом на Github.

Краткое описание аукционной системы

Аукционная система — это просто система, в которой конкретный продукт продается тому, кто предложит самую высокую цену; покупатель, который готов платить больше, чем другие покупатели. Таким образом, эта система должна имитировать решение для онлайн-аукциона, где пользователи могут регистрироваться на платформе, и у нас есть несколько администраторов для управления сайтом. Ниже приведен список нескольких операций, которые можно выполнять на платформе.

Users can: create account, create auction, view all auctions, view auction created by self, view all bids on an auction, bid on an auction.
Admins can: view all users, delete user, create auction, view all auctions, delete auction, view all bids on an auction, end bidding by declaring winner.

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

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

Затем мы можем установить Jest с помощью npm:

npm install --save-dev jest

После установки Jest перейдите к package.json и установите для свойства test в свойствах объекта скрипта значение jest --coverage.

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

Синтаксис Jest и сопоставления

Все фреймворки для тестирования имеют собственный синтаксис. Типичный синтаксис Jest будет выглядеть так:

Давайте быстро пройдемся по некоторым ключевым словам, которые у нас есть выше;

describe() and it() являются шутливыми методами, действующими как оболочка тестов. Их первый аргумент описывал в строке то, чего пытается достичь отдельный тест или группа тестов. И затем у нас есть expect().toEqual(), что, говоря простым языком, означает, что мы ожидаем, что конкретная функция или метод будут равны чему-то, что мы предопределили. toEqual() — это сопоставитель, который сопоставляет тип возвращаемого значения тестируемого метода с нашим предопределенным результатом и проверяет каждое поле объекта или массива. Существуют и другие сопоставители, которые мы можем использовать в тестовых примерах в зависимости от типа возвращаемого значения и поведения тестируемого метода.

Следующие процедуры TDD:

Приступим к разработке нашей системы;

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

Запустите тест: мы можем использовать эту команду для запуска нашего набора тестов для шуток: npm test

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

Напишите минимальный объем кода для прохождения теста: здесь мы можем разработать метод createUser(), который создаст и сохранит пользователя в db.js.

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

Ага! Все испытания прошли.

Убедитесь, что все ваши ветки кода полностью покрыты. это означает, что вы должны стремиться получить 100% баллов по всем параметрам теста покрытия. Это каким-то образом поможет вам отслеживать избыточные операторы кода.

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

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

Позвольте мне быстро показать вам еще один сопоставитель при тестировании метода, возвращающего точную строку. Например, тестирование метода, возвращающего победителя аукциона.

describe(‘Admin can declare winner to auction’, () => {
it(‘Admin can show the winner of an auction by auctionID’, () => {
expect(mark.winnerAuction(2)).toMatch(/^Tommy$/);
});
});

mark.winnerAuction(2) должен вернуть Tommy как победителя аукциона. mark является администратором и может выполнять только эту операцию. Метод принимает в качестве аргумента Id конкретного аукциона. у нас есть toMatch сопоставитель, который проверяет строки на соответствие регулярным выражениям.

В конце нашей разработки у нас должен быть такой тест и результат теста;

Всего у нас 16 тестов. Если в какой-то момент ваш производственный код дает сбой или дает сбой, ваши тестовые примеры могут быстро показать вам, откуда возникает ошибка.

Вывод

Мы только что рассмотрели, как тестировать коды в Javascript. Однако кажется, что практика TDD обычно требует больше времени, но на самом деле TDD помогает как разработчику, так и клиенту сэкономить время и деньги в долгосрочной перспективе, когда необходима масштабируемость. Предполагаемый кошмар TDD — тщательное продумывание кода еще до того, как код написан. Но его преимущество огромно и стоит.

Если вам нужна дополнительная информация о том, как полностью использовать фреймворк Jest, вы можете ознакомиться с их документацией здесь.

Ознакомьтесь с полной реализацией тестирования нашей Аукционной системы в репозитории Github.

Спасибо за ваше чтение, и, пожалуйста, похлопайте мне, если вам понравилась эта статья.