Модульное тестирование JavaScript для начинающих

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

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

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

Что такое модульное тестирование?

Модульный тест запускает некоторый код в сегменте вашей программы, проверяя ввод и вывод. Эти тесты позволяют разработчикам проверять отдельные области программы, чтобы увидеть, где (и почему) возникают ошибки.

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

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

В мире JavaScript все может быть немного сложнее, потому что он работает во внешнем интерфейсе веб-страницы. Самый простой способ справиться с этим — использовать отдельные библиотеки JS.

Но как на самом деле написать модульные тесты и извлечь из них какую-то пользу? Ответ зависит от вашего кода, поэтому у разработчика C++ другая методология, чем у разработчика JavaScript.

Давайте немного углубимся в модульное тестирование для JS и посмотрим, как этого можно добиться.

Фронтенд JS-тестирование

Нет необходимости в модульном тестировании для HTML/CSS, поскольку они не являются языками, основанными на функциях. JavaScript — это настоящий скрипт, и с новыми ресурсами, такими как Node.js и TypeScript, он становится намного мощнее.

Простое модульное тестирование JS будет принимать функцию, отслеживать вывод и возвращать ее поведение. У Smashing Magazine есть отличный пример, который тестирует функцию вывода календарной даты на основе определенного типа ввода.

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

Каждый модульный тест предназначен для проверки отдельного модуля в JavaScript, который обычно разбивается на функцию или библиотеку. Цель состоит в том, чтобы проверить каждый аспект функции, чтобы убедиться, что все работает правильно во всех случаях.

Частая тема споров — между TDD и BDD для модульного тестирования. Разработка через тестирование (TDD) в основном аналогична разработке через поведение (BDD), но с другой терминологией и подходами.

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

Таким образом, вместо того, чтобы создавать функции исключительно с помощью логики, вы думаете о том, как пользователь может отправить ввод и как этот ввод может быть передан в JavaScript (например, неэкранированный HTML-код). Метод TDD принимает это как необработанные данные, тогда как метод BDD сначала рассматривает поведение, а затем данные.

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

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

Методы и стратегии

Как только вы поймете, что тестируете, вы захотите приступить к написанию теста. Но что именно вы должны проверить?

Наиболее распространенный сценарий — это ввод и действия пользователя. Допустим, пользователь входит в систему и хочет установить файл cookie. Настройка файлов cookie — это особое поведение, которое следует тестировать на основе нескольких результатов (сбой и успешный вход в систему).

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

Какую функцию/проблему вы тестируете?
Что вышло после запуска теста?
Каков ожидаемый результат успешного теста?

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

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

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

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

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

Что такое модули Javascript?

Angular 2 против React.js — что подходит именно вам?

Как сделать игровой цикл в JavaScript

Лучшие инструменты для тестирования JS

Если вы действительно не любите писать ванильный JS, вам следует работать с JS-библиотеками. Лучшие из них ускорят ваш рабочий процесс и предоставят безошибочные библиотеки для тестирования вашего потенциально нагруженного ошибками кода.

Жасмин.js

Нельзя отрицать, что Jasmine — одна из самых популярных библиотек модульного тестирования на основе JS в Интернете. Он полностью бесплатный, с открытым исходным кодом и часто обновляется новыми функциями.

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

На момент написания этой статьи последняя версия Jasmine — v2.4 с большим количеством поддержки. Если вы ищете бесплатный учебник, я бы порекомендовал вам эту статью Tuts+, чтобы вы могли начать.

QUnit

Один из самых безопасных вариантов — QUnit. Эта среда модульного тестирования JavaScript была создана командой jQuery и используется во всех их проектах (включая jQuery UI и jQuery Mobile).

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

Мокко.js

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

По умолчанию Mocha — это тестовая библиотека, которая может работать с другими библиотеками, такими как Chai.js, для тестирования утверждений. Chai позволяет получить больше, чем базовые результаты теста истина/ложь, и повышает гибкость, которую вы уже получаете с Mocha.

Это одна из лучших библиотек, которую вы можете выбрать для начала работы. Он обрабатывает все асинхронные методы и работает на Node.js, как и многие другие современные JS-библиотеки.

Стажер

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

Тесты можно запускать в браузере или запускать в пользовательском Intern test runner. Он может запускать тесты на сторонних фреймворках, таких как BrowserStack, и поддерживает все возможные фреймворки JS, которые вы только можете себе представить.

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

Здесь слишком много вариантов, чтобы перечислять их, так что решать вам. Честно говоря, вы не ошибетесь в любом случае, даже если хотите создать свою собственную библиотеку с нуля!

Но если вы ищете более удобные инструменты тестирования, я настоятельно рекомендую эти альтернативные (и бесплатные) решения.

Лучший способ понять модульное тестирование — просто попробовать его в своем следующем проекте. Не всем нужно писать модульные тесты, поэтому эти принципы могут не применяться к небольшим личным проектам.

Но если вы работаете в команде или планируете запустить гораздо более крупный проект, полезно выработать привычку к модульному тестированию кода. Я, конечно же, надеюсь, что это руководство поможет вам начать работу и предложит лучшие ресурсы для продолжения вашего путешествия по модульному тестированию JS.