Введение в модульное тестирование JavaScript

1. Об авторе
2. Дальнейшее чтение на SmashingMag:
3. Сборка юнит-тестов
4. Сделайте вещи проверяемыми
5. Рефакторинг, Стадия 0
6. Тестовый набор QUnit JavaScript
7. Рефакторинг, 1 этап
8. Тестирование манипуляции с DOM
9. Рефакторинг, 2 этап
10. Вернуться к началу
11. Заключение

Об авторе

Йорн - независимый веб-разработчик, консультант и тренер, проживающий в Кельне, Германия. Йорн развил набор тестов jQuery в QUnit, модульное тестирование JavaScript… Подробнее о Йорне ...

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

Вероятно, это тот случай, когда не используется библиотека JavaScript для некоторой абстракции DOM; писать встроенные обработчики событий гораздо проще, чем использовать API-интерфейсы DOM для привязки этих событий. Все больше и больше разработчиков выбирают библиотеку, такую ​​как jQuery, для обработки абстракции DOM, что позволяет им перемещать эти встроенные события в отдельные сценарии, либо на одной странице, либо даже в отдельном файле JavaScript. Однако размещение кода в отдельных файлах не означает, что он готов для тестирования как единое целое.

Дальнейшее чтение на SmashingMag:

Что такое подразделение в любом случае? В лучшем случае это чистая функция, с которой вы можете иметь дело каким-то образом - функция, которая всегда дает вам один и тот же результат для данного ввода. Это делает модульное тестирование довольно простым, но большую часть времени вам приходится иметь дело с побочными эффектами, которые здесь означают манипуляции DOM. По-прежнему полезно выяснить, в какие модули мы можем структурировать наш код, и соответственно построить модульные тесты.

Сборка юнит-тестов

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

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

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

Этого должно быть достаточно теории на данный момент. Давайте рассмотрим практический пример тестирования некоторого кода JavaScript, который в настоящее время смешан со страницей и подключен к ней. Код ищет ссылки с атрибутами заголовка, используя эти заголовки для отображения, когда что-то было опубликовано, в виде относительного значения времени, например «5 дней назад»:

Если вы запустите этот пример, вы увидите проблему: ни одна из дат не будет заменена. Код работает, хотя. Он просматривает все якоря на странице и проверяет свойство заголовка на каждом. Если он есть, он передает его функции prettyDate. Если prettyDate возвращает результат, он обновляет innerHTML ссылки с результатом.

Сделайте вещи проверяемыми

Проблема в том, что для любой даты старше 31 дня prettyDate просто возвращает undefined (неявно, с одним оператором return), оставляя текст привязки как есть. Итак, чтобы увидеть, что должно произойти, мы можем жестко закодировать «текущую» дату:

Теперь ссылки должны сказать «2 часа назад», «Вчера» и так далее. Это что-то, но все еще не фактический тестируемый модуль. Таким образом, без дальнейшего изменения кода, все, что мы можем сделать, это попытаться проверить полученные изменения DOM. Даже если бы это сработало, любое небольшое изменение в разметке, вероятно, сломало бы тест, что привело бы к очень плохому соотношению затрат и выгод для такого теста.

Рефакторинг, Стадия 0

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

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

Вот содержимое файла prettydate.js:

Теперь, когда у нас есть что проверить, давайте напишем несколько реальных модульных тестов:

• Запустите этот пример. (Обязательно включите консоль, например Firebug или Chrome Web Inspector.)

Это создаст специальную среду тестирования, используя только консоль для вывода. У него вообще нет никаких зависимостей от DOM, так что вы можете с таким же успехом запускать его в не-браузерной среде JavaScript, такой как Node.js или Rhino, извлекая код из тега script в его собственный файл.

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

Если все тесты пройдены, как и здесь, вы увидите следующее в консоли:

Чтобы увидеть, как выглядит ошибочное утверждение, мы можем что-то изменить, чтобы сломать его:

Из 6 тестов 1 не пройден, 5 пройден.

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

Тестовый набор QUnit JavaScript

Выбор каркаса в основном зависит от вкуса. В оставшейся части этой статьи мы будем использовать QUnit (произносится как «q-unit»), потому что его стиль описания тестов близок к нашему специальному тестовому фреймворку.

Три раздела заслуживают более пристального внимания. Наряду с обычным шаблоном HTML у нас есть три включенных файла: два файла для QUnit (qunit.css и qunit.js) и предыдущий prettydate.js.

Затем есть еще один блок скрипта с реальными тестами. Тестовый метод вызывается один раз, передавая строку в качестве первого аргумента (называя тест) и передавая функцию в качестве второго аргумента (который запустит реальный код для этого теста). Затем этот код определяет переменную now, которая снова используется ниже, а затем несколько раз вызывает равный метод с различными аргументами. Метод равных является одним из нескольких утверждений, которые предоставляет QUnit. Первый аргумент является результатом вызова prettyDate с переменной now в качестве первого аргумента и строкой даты в качестве второго. Второй аргумент, равный ожидаемому результату. Если два равных аргумента имеют одно и то же значение, то утверждение пройдет; в противном случае это не удастся.

Наконец, в элементе body есть некоторая разметка, специфичная для QUnit. Эти элементы являются необязательными. Если он присутствует, QUnit будет использовать их для вывода результатов теста.

Результат таков:

В случае неудачного теста результат будет выглядеть примерно так:

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

Рефакторинг, 1 этап

Утверждения в настоящее время несколько неполны, потому что мы еще не тестировали вариант n недель назад. Прежде чем добавить его, мы должны рассмотреть возможность рефакторинга тестового кода. В настоящее время мы вызываем prettyDate для каждого утверждения и передаем аргумент now. Мы могли бы легко преобразовать это в собственный метод утверждения:

Здесь мы извлекли вызов prettyDate в функцию date, вставив переменную now в функцию. В результате мы получаем только соответствующие данные для каждого утверждения, что облегчает их чтение, в то время как основная абстракция остается довольно очевидной.

Тестирование манипуляции с DOM

Теперь, когда функция prettyDate протестирована достаточно хорошо, давайте вернемся к первоначальному примеру. Наряду с функцией prettyDate он также выделил некоторые элементы DOM и обновил их в обработчике событий загрузки окна. Применяя те же принципы, что и раньше, мы должны иметь возможность реорганизовать этот код и протестировать его. Кроме того, мы введем модуль для этих двух функций, чтобы не загромождать глобальное пространство имен и иметь возможность давать этим отдельным функциям более значимые имена.

Вот содержимое prettydate2.js:

Новая функция prettyDate.update является выдержкой из исходного примера, но с аргументом now, передаваемым в prettyDate.format. Тест для этой функции на основе QUnit начинается с выбора всех элементов в элементе # qunit-fixture. В обновленной разметке в элементе body <div id = «qunit-fixture»>… </ div> является новым. Он содержит фрагмент разметки из нашего исходного примера, достаточный для написания полезных тестов. Помещая его в элемент # qunit-fixture, нам не нужно беспокоиться об изменениях DOM из одного теста, влияющих на другие тесты, поскольку QUnit автоматически сбрасывает разметку после каждого теста.

Давайте посмотрим на первый тест для prettyDate.update. После выбора этих якорей два утверждения проверяют, имеют ли они исходные текстовые значения. После этого вызывается prettyDate.update с фиксированной датой (такой же, как в предыдущих тестах). После этого выполняются еще два утверждения, теперь проверяющих, что свойство innerHTML этих элементов имеет правильно отформатированную дату: «2 часа назад» и «Вчера».

Рефакторинг, 2 этап

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

Здесь у нас есть новая функция domtest, которая инкапсулирует логику двух предыдущих вызовов test, вводя аргументы для имени теста, строки даты и двух ожидаемых строк. Затем он вызывается дважды.

Вернуться к началу

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

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

Заключение

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

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

(ал) (км)