Как сделать тест на js

Добавил пользователь Евгений Кузнецов
Обновлено: 04.10.2024

Существует много видов тестирования, но в основном короткие тесты делятся на три основные категории:

модульное или как его еще называют юнит тестирование
интеграционное тестирование
UI тестирование

В этом руководстве Jest мы рассмотрим только модульное тестирование, но в конце статьи вы найдете ресурсы для других типов тестов.

Jest Tutorial: что такое Jest?

Jest — это JavaScript-тестер (test runner), то есть библиотека JavaScript для создания, запуска и структурирования тестов. Jest распространяется в виде пакета NPM, вы можете установить его в любом проекте JavaScript. Jest — один из самых популярных тестеров в наши дни, который по умолчанию используется для Create React App.

Перво-наперво: откуда мне знать, что тестировать?

вы наследуете устаревший код, который поставляется без тестов
Вы должны реализовать новую функциональность с нуля.

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

импортируем функцию для тестирования
предоставляем входные параметры функции
определяем что ожидается на выходе
проверить соответствует ли это то что возвращает функция

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

Jest Tutorial: настройка проекта

Как и в каждом проекте JavaScript, вам потребуется среда NPM (убедитесь, что в вашей системе установлен Node). Создайте новую папку и инициализируйте проект:

Затем установите Jest:

Теперь все готово!

Jest Tutorial: спецификации и разработка на основе тестирования

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

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

По умолчанию Jest ожидает найти тестовые файлы в папке с именем __tests__ в папке вашего проекта. Создайте новую папку, затем:

А теперь давайте пройдем тестирование!

Jest Tutorial: тестовая структура и первый провальный тест

Время создать свой первый тест Jest. Откройте filterByTerm.spec.js и создайте тестовый блок:

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

Далее мы встретимся с другой функцией под названием test, которая является фактическим тестовым блоком:

На данный момент мы готовы написать тест. Помните, что тестирование — это вопрос входных данных, функций и ожидаемых результатов. Сначала давайте определим простые входные данные, массив объектов:

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

И теперь мы готовы написать реальный тест. Мы будем использовать функцию expect и Jest matcher для проверки того, что наша фиктивная (пока) функция возвращает ожидаемый результат при вызове. Вот тест:

Там образом мы определили как мы должны вызывать поисковую функцию в своем коде:

В тесте Jest нужно обернуть вызов функции в expect, которые в сочетании с matcher (функция Jest для проверки выходных данных) выполняет фактические тесты. Вот полный код:

(Чтобы узнать больше о Jest matchers, ознакомьтесь с документацией).

Запустим наш тест:

Вы увидите что тест не проходит:

«ReferenceError: filterByTerm is not defined. Это хорошая вещь на самом деле. Давайте исправим это в следующем разделе!

Jest Tutorial: исправление теста (и повторение его)

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

Для выполнения теста мы будем использовать встроенную функцию JavaScript под названием filter, которая способна отфильтровывать элементы из массива. Вот минимальная реализация filterByTerm:

Теперь запустите тест снова:

и увидеть, как он проходит!

Отличная работа. Но закончили ли мы тестирование? Еще нет. Что нужно, так это чтобы наша функция перестала работать. Добавим тестирование с поисковым термином в верхнем регистре:

Jest Tutorial: исправление теста в верхнем регистре

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

Для проверки этого условия мы ввели новый тест:

Чтобы сделать это, мы можем настроить регулярное выражение для match:

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

И вот полный тест:

Запустите его снова и убедитесь что оно проходит. Отличная работа! В качестве упражнения для вас напишите два новых теста и проверьте следующие условия:

Как бы вы структурировали эти новые тесты?

В следующем разделе мы увидим еще одну важную тему в тестировании: покрытие кода.

Jest Tutorial: покрытие кода

Что такое покрытие кода? Прежде чем говорить об этом, давайте сделаем небольшую корректировку нашего кода. Создайте в корневом каталоге вашего проекта новую папку с именем src и создайте файл с именем filterByTerm.js, в который мы поместим и экспортируем нашу функцию:

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

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

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

через командную строку, передав флаг «—coverage«
настроив Jest в package.json

Перед запуском теста с покрытием обязательно импортируйте filterByTerm в tests/filterByTerm.spec.js:

Сохраните файл и запустите тест с покрытием:

Вот что вы получаете:

Хорошее резюме покрытия тестирования для нашей функции. Как вы можете видеть, строка 3 раскрыта. Попробуйте достичь 100% покрытия кода, протестировав новое утверждение, которое я добавил.

Если вы хотите, чтобы покрытие кода всегда было активным, настройте Jest в package.json следующим образом:

Вы также можете передать флаг тестовому скрипту:

Если вы хотите это визуализировать, есть также способ получить отчет в формате HTML для покрытия кода, просто настройте Jest следующим образом:

Теперь каждый раз, когда вы запускаете тест npm, вы можете получить доступ к новой папке с именем coverage в папке вашего проекта: getting-started-with-jest/coverage/. Внутри этой папки вы найдете несколько файлов, где /coverage/index.html — это полная сводка HTML покрытия вашего кода:

Если вы нажмете на имя функции, вы также увидите точную непроверенную строку кода:

Аккуратно? С покрытием кода вы можете узнать, что тестировать, если сомневаетесь.

Jest Tutorial: как протестировать React?

React — очень популярная библиотека JavaScript для создания динамических пользовательских интерфейсов. Jest отлично работает для тестирования приложений React (Jest и React от инженеров Facebook). Jest также является test runner по умолчанию в Create React App.

Если вы хотите узнать, как тестировать компоненты React, ознакомьтесь с разделом Testing React Components: The Mostly Definitive Guide. Руководство охватывает компоненты модульного тестирования, компоненты класса, функциональные компоненты с хуками и новый Act API.

Заключение

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

Чтобы узнать больше о UI тестировании, я настоятельно рекомендую взглянуть на JavaScript End to End Testing with Cypress.

Даже если это не связано с JavaScript, я также предлагаю прочитать Test-Driven Development with Python от Гарри Персиваля. Он полон советов и подсказок по всем вопросам тестирования и подробно описывает все виды тестов.

Если вы готовы сделать скачок и узнать об автоматизированном тестировании и непрерывной интеграции, то Automated Testing and Continuous Integration in JavaScript для вас.

Вы можете найти код для этого урока на Github: getting-started-with-jest, а также решение для упражнений.

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

Написание модульных тестов для проекта на основе CLI (ESPROJ)

Проекты на основе CLI, поддерживаемые в Visual Studio 2022, работают с обозревателем тестов. Jest — это встроенная платформа тестирования для проектов React и Vue, а Karma и Jasmine используются для проектов Angular. По умолчанию вы сможете выполнять тесты, по умолчанию предоставляемые каждой платформой, а также любые дополнительные тесты, которые вы создаете. Просто нажмите кнопку Выполнить в обозревателе тестов. Если вы еще не открыли обозреватель тестов, выберите в строке меню пункт Тест > Обозреватель тестов.

Для поддержки модульного тестирования для проектов на основе CLI требуется рабочая нагрузка "Разработка Node.js".

Также поддерживаются библиотеки тестов Mocha и Tape. Чтобы использовать один из них, просто измените библиотеку тестирования по умолчанию в файле package.json на соответствующий пакет библиотеки тестов.

Написание модульных тестов в проекте Node.js (.njsproj)

Прежде чем добавлять модульные тесты в проект Node.js, убедитесь, что выбранная платформа установлена в нем локально. Это легко сделать в окне установки пакета npm.

Чтобы добавлять в проект модульные тесты, рекомендуется создать в проекте папку tests и настроить ее как тестовый корень в свойствах проекта. Также необходимо выбрать желаемую платформу тестирования.

Вы можете добавлять в проект простые пустые тесты в диалоговом окне Добавить новый элемент. В одном проекте поддерживаются JavaScript и TypeScript.

Для модульного теста Mocha используйте следующий код:

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

Параметры модульного теста имеют приоритет над параметрами отдельных файлов.

После открытия обозревателя тестов (выберите Тест > Windows > Обозреватель тестов) Visual Studio обнаруживает и отображает тесты. Если тесты не отображаются изначально, перестройте проект, чтобы обновить список.

В файле tsconfig.json TypeScript не используйте параметр outdir или outfile , так как обозреватель тестов не сможет найти модульные тесты.

Выполнение тестов (Node.js)

Вы можете выполнять тесты в Visual Studio или из командной строки.

Выполнение тестов в Visual Studio

Чтобы выполнить тест, нажмите на ссылку Выполнить все в обозревателе тестов. Или выберите один или несколько тестов или групп, щелкните правой кнопкой мыши и в контекстном меню выберите команду Выполнить. Тесты выполняются в фоновом режиме, и обозреватель тестов автоматически обновится, отображая результаты. Кроме того, вы можете отладить выбранные тесты, щелкнув их правой кнопкой мыши и выбрав Отладить.

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

Для TypeScript модульные тесты выполняются в созданном коде JavaScript.

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

В настоящее время мы не поддерживаем тесты профилирования или объем протестированного кода.

Запуск тестов из командной строки

Вы можете выполнять тесты из командной строки разработчика в Visual Studio, используя следующую команду:

Выходные данные этой команды выглядят примерно следующим образом:

Для добавления поддержки TypeScript используйте пакет NuGet вместо пакета npm TypeScript.

В обозревателе решений щелкните узел проекта правой кнопкой мыши и выберите Выгрузить проект.

Файл .csproj должен быть открыт в Visual Studio.

Добавьте следующие элементы в файл .csproj в элементе PropertyGroup .

В этом примере в качестве платформы тестирования используется Mocha. Вместо нее можно указать Jest, Tape или Jasmine.

Элемент JavaScriptTestRoot указывает, что модульные тесты будут находиться в папке tests корневого каталога проекта.

В обозревателе решений щелкните узел проекта правой кнопкой мыши и выберите Выгрузить проект.

Для этого необходимо установить среду выполнения Node.js для поддержки npm и добавить package.js в корневую папку проекта.

В файле package.json добавьте необходимый пакет npm в разделе зависимостей.

Например для mocha можно использовать следующий код JSON:

Для некоторых платформ модульного тестирования, таких как Jest, требуются дополнительные пакеты npm. Для Jest используйте следующий код JSON:

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

Добавьте код в тест.

Для TypeScript модульные тесты выполняются в созданном коде JavaScript.

Добавьте модульные тесты в папку tests в корневом каталоге проекта.

Например, вы можете использовать следующий код, выбрав вкладку документации, соответствующую вашей платформе тестирования, в данном случае, Mocha или Jest. Этот код проверяет функцию с именем getData .

Откройте обозреватель тестов (выберите Тест > Windows > Обозреватель тестов), и тесты будут обнаружены и показаны в Visual Studio. Если тесты не отображаются изначально, перестройте проект, чтобы обновить список.

В файле tsconfig.json TypeScript не используйте параметр outfile , так как обозреватель тестов не сможет найти модульные тесты. Можно использовать параметр outdir , но убедитесь, что в корневом каталоге проекта есть файлы конфигурации, такие как package.json и tsconfig.json .

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

Для TypeScript модульные тесты выполняются в созданном коде JavaScript.

В настоящее время мы не поддерживаем тесты профилирования или объем протестированного кода.

Расширение поддержки платформ модульного тестирования

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

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

Эта папка должна содержать файл JavaScript с тем же именем, который экспортирует следующие две функции:

Хороший пример реализаций find_tests и run_tests есть в реализации для платформы модульного тестирования Mocha:

Обнаружение доступных тестовых платформ выполняется при запуске Visual Studio. Если платформа добавляется во время выполнения Visual Studio, перезапустите Visual Studio для обнаружения платформы. Но вам не нужно перезапускать платформу, если вы вносите изменения в реализацию.

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

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

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

В дополнение к указанным выше свойствам вам необходимо также установить пакет NuGet Microsoft.JavaScript.UnitTest и установить следующее свойство:

Некоторым платформам тестирования могут потребоваться дополнительные пакеты npm для обнаружения тестов. Например, для jest требуется пакет npm jest-editor-support. При необходимости ознакомьтесь с документацией по конкретной платформе.

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

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

б) Нужно, куда-то, вводить вопросы.

в) Нужно обрабатывать ответы. Чтобы система определила правильно или неправильно.

г) Нужно вывести результат.

Итого, получается 4 пункта. Чтобы был порядок в нашем тесте. Создадим 4 формы, где и будем реализовывать наши команды алгоритма.

В первой форме будем помещать наши вопросы.

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

Эта форма мною названа именем L , здесь 4 интервала. Начинаются соответственно с 0,4,7,10. Вы можете проставлять свои варианты.

input type =" hidden " – означает, что эти величины не отображаются на экране при запуске теста.

Для этого вводим еще одну форму D

Вы можете прописывать свои комментарии к оцениванию.

Теперь приступаем к обработке:

Ну и теперь вводим форму на которую будем выводить результат

Приветствую вас дорогие друзья! В сегодняшнем выпуске мы рассмотрим тест, написанный на javascript! Совсем недавно я рассказывал как проверить билетик – счастливый или нет, сегодня мы создадим простецкий тест и как всегда в конце статьи будет Demo пример. Итак, давайте сначала разберем структуру нашего теста..

Из чего состоит тест?

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

Где хранить вышеперечисленные данные?

Хранить все необходимые данные мы будет в массивах, так как с ними легко работать, добавлять новые элементы и удалять элементы. В нашем случае структура хранения данных будет выглядеть следующим образом:

Массив questions В данном массиве содержатся вопросы (в нашем примере – это слова на русском либо на английском языке). Массивы number1 (2,3,4) Четыре данных массива предназначены для хранения вариантов ответа.

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

Особенности теста

Первая особенность: тест начинается по нажатию на кнопку – "Приступить к тесту" – после нажатия, данная кнопка исчезает и появляется тест и также кнопка завершения.

Вторая: Имеется кнопка ("Начать сначала"), соответственно, позволяющая начать тест с самого начала.

Функция check – эта единственная функция, которая и отвечает за сам процесс тестирования. Она имеет один (1) параметр – их примеры: check(4) – это означает, что нужно запустить тест check(5) – это означает, что нужно запустить тест заново. Такие значения параметров, как: 0,1,2,3 – означают соответствующие варианты ответа. Думаю, все остальное понятно из кода.

Как его использовать на своем сайте?

Демо пример

Вот так вот он выглядит в работе..

На этом пример на javascript подошел к концу, желаю вам удачи и до скорых встреч! Добавлен улучшенный тест 05.01.2017: Как сделать тест на javascript с ответами?

Дата последнего изменения: 2019-01-05 21:15:28

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

Создание простого теста

Развитие информационных технологий и дистанционного образования приводит к необходимости создания электронных учебных тестов. Многие учителя и преподаватели сталкиваются с проблемой создания учебных тестов. Главная сложность решения данной задачи в том, что при создании таких электронным материалов требуется знание HTML и jаvascript.

Как решить эту проблему. Учитель может воспользоваться онлайн конструктором тестов или же попытаться создать тест самостоятельно на основе использования шаблона. Именно второй вариант мы рассмотрим в данной статье.

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

Допустим имеется несложный математический тест, состоящий из нескольких задач по математике:

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

Сначала создадим HTML код задач:

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

Обратите внимание на идентификаторы “z_1”,”z_2” и “z_3”. Если вам нужно добавить задачу 4, то нужно просто скопировать последнюю строку с задачей, заменить условие и в поле идентификатора написать “z_4”.

В последней строке мы покажем результат выполнения заданий после проверки.

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

pr_otv_zadachi_1 = 55;
pr_otv_zadachi_2 = -9;
pr_otv_zadachi_3 = 85;

Первые три строки будут содержать правильные ответы. Четвертая и последующие задачи в тест добавляются путем копирования последней строки с ответом, подстановки числа 4 вместо 3 и указанием правильного ответа.

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

otv_uch_1 = document.getElementById(‘z_1’).value;
otv_uch_2 = document.getElementById(‘z_2’).value;
otv_uch_3 = document.getElementById(‘z_3’).value;

Четвертая задача будет означать новую строку с заменой цифр 3 на 4.

Далее нужно сравнить ответы ученика с правильными ответами. Если ответы будут совпадать, то за каждую задачу теста нужно добавить 1 балл.

ball = 0;
if(otv_uch_1 == pr_otv_zadachi_1)
if(otv_uch_2 == pr_otv_zadachi_2)
if(otv_uch_3 == pr_otv_zadachi_3)

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

JavaScript уже не тот

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

Что я подразумеваю под практиками и парадигмами? Конечно же, архитектурный шаблон MVC (model view controller) и паттерны организации кода. Следуя этим не хитрым премудростям, ты сможешь писать более качественный код, который будет не только легко сопровождаться, но обладать способностью к автоматическому тестированию.

Ошибка большинства тестеров

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

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

Unit тесты как серебряная пуля

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

После завершения разработки новой функции (возможен вариант написания тестов и до начала разработки) девелопер пишет специальный код для тестирования своего кода. В коде для тестирования нужно сымитировать различные ситуации и возвращаемые значения. Например, мы написали функцию для усечения пробелов (trim). Чтобы протестировать ее работоспособность мы должны подготовить несколько тестов, которые позволят утверждать, что:

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

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

Тесты != лишний код

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

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

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

Не всякий код тестируется

Почему я утверждаю, что задумываться о тестировании нужно до написания основного кода? Да потому, что код, который изначально предполагается покрывать unit-тестам, пишется в несколько другом стиле. Не всякий код можно протестировать. Код, в котором смешивается логика и представления, да еще и распиханный где невозможно нормально протестировать. Тут я всегда советую придерживаться нескольким простым правилам:

QUnit – классика жанра от создателей jQuery

QUnit пользуется особой популярностью среди JavaScript разработчиков. Во-первых, она отлично документирована и проста в использовании, а во-вторых она создана авторами jQuery. Библиотека подходит как для тестирования кода, созданного на базе jQuery, так и нативного JavaScript.

Для демонстрации тестов я создал простейший проект со следующей структорой:

Содержимое файла index.html и test.js представлено в листинге 1 и 2. Больше всего нас интересует второй листинг, в котором приведено объявление тестируемой функции (trim()) и код тестов для проверки ее работоспособности. Обрати внимание, сама функция trim() может располагаться где угодно, я ее засунул во второй листинг только ради экономии места в журнале.

Теперь посмотрим на сами тесты. Для осуществления проверок работоспособности нашего кода библиотека Qunit.js предлагает нам ряд методов:

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

Листинг 1. Содержимое файла index.html

Листинг 2. Файлы тестов и функция trim()

С тестированием простых функций вроде разобрались. Во всяком случае, мне добавить больше нечего. Дальше надо брать реальный код и пробовать писать тесты самостоятельно. Посмотрим на другую, часто возникающую задачу перед JavaScript-разработчиками – тестирование асинхронных функций. Приложение, напичканное JavaScript-кодом, в 99% взаимодействует с серверной частью при помощи Ajax. Оставлять этот код без проверки также нельзя, но написание тестов будет выглядеть немного по-другому. Рассмотрим пример:

Главное отличие этого примера от предыдущего – вместо обертки test() применяется asyncTest(), тем самым напрямую заявляя, что меня интересует тестирование именно асинхронное тестирование. Дальше я запускаю время ожидание в 500 мл. сек. За это время функция myAsyncFunc() должна передать данные на тестовый сервер, и если все ништяк вернуть true. Вот здесь наступает самый интересный момент. Когда происходит вызов asyncTest() поток выполнения останавливается и по окончанию теста его необходимо самостоятельно запустить. Для управления потоком выполнения в QUnit есть методы start() и stop().

Тестирование асинхронных функций с помощью библиотеки QUnit выполняется достаточно просто. Последний пример, который мне хотелось бы разобрать, связан с написанием теста, выполняющий несколько асинхронных проверок. Главный вопрос, который возникает на этом в подобных задачах – оптимальное место для старта потока выполнения. Официальный док предлагает применять в этих случаях что-то вроде:

Тест для пользовательских действий

Листинг 3. Логирование нажатых клавиш

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

Листинг 4. Код теста для KeyLogger

DOM под прикрытием тестов

Раз Qunit.js позволяет тестировать пользовательские действия, то с написанием тестов для DOM тоже не должно быть проблем. Это действительно так и приведенный пример ниже подтвердит мои слова. Я не буду его комментировать, просто взгляни на код и все станет понятным:

Phantom.JS – запускаем тесты из консоли

Писать тесты с помощью библиотеки Qunit.js удобно и просто, но рано или поздно ее тебя посетит желание как-то автоматизировать запуск тестирование и сбор результатов. Например, у меня для этого дела есть отдельная виртуальная машина в DigitalOcean, управлять которой я могу лишь при помощи консоли.

Достаточно элегантно эту проблему позволяет решить проект phantom.js. Это не очередной фреймворк для написания Unit-тестов, а полноценная консольная версия движка WebKit. Если сказать проще, то это приложение эмулирует браузер. При помощи phantom.js реально не просто автоматизировать проверку выполнения тестов, но и решить множество задач, рано или поздно возникающих перед разработчиком: получение результатов рендинга страниц в файл (png, jpg), функции сетевого монитора (скорость загрузки, общая производительность и т.д.), эмуляция действий пользователя и т.д. Рекомендую не полениться и почитать официальную документацию по этому проекту, обязательно найдешь что-то интересное для себя.

Phantom.js можно собрать под разные платформы (nix, mac OS X, windows). Если ты все разрабатываешь под Windows, то нет никаких проблем – сливай бинарники и вперед. Небольшие проблемы с запуском могут возникнуть, если у тебя установлено два видео адаптера, один из которых NVidia. В этом случае тебе придется воспользоваться хаком, описанном во врезке.

Попробуем познакомиться с phantom.js на практике. Чтобы пропустить через phantom.js тесты, подготовленные в прошлом разделе и получить результаты выполнения в консоль нам потребуется специальный сценарий-лоадер – run-qunit.js. Открываем консоль (я работаю в Windows, поэтому использую cmd) и набиваем команду в формате:

В моем случае команда запуска получилась такой:

All tests passed

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

Когда на тесты нет времени

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

Читайте также: