Автоматические тесты при помощи chai и mocha
Материал на этой странице устарел, поэтому скрыт из оглавления сайта.
Более новая информация по этой теме находится на странице https://learn.javascript.ru/testing-mocha.
В этой главе мы разберём основы автоматического тестирования. Оно будет применяться далее в задачах, и вообще, входит в «образовательный минимум» программиста.
Зачем нужны тесты?
При написании функции мы обычно представляем, что она должна делать, какое значение на каких аргументах выдавать.
В процессе разработки мы время от времени проверяем, правильно ли работает функция. Самый простой способ проверить – это запустить её, например в консоли, и посмотреть результат.
Если что-то не так, поправить, опять запустить – посмотреть результат… И так «до победного конца».
Но такие ручные запуски – очень несовершенное средство проверки.
Когда проверяешь работу кода вручную – легко его «недотестировать».
Автоматизированное тестирование – это когда тесты написаны отдельно от кода, и можно в любой момент запустить их и проверить все важные случаи использования.
BDD – поведенческие тесты кода
Мы рассмотрим методику тестирования, которая входит в BDD – Behavior Driven Development. Подход BDD давно и с успехом используется во многих проектах.
BDD – это не просто тесты. Это гораздо больше.
Тесты BDD – это три в одном: И тесты, И документация, И примеры использования.
Впрочем, хватит слов. Рассмотрим примеры.
Разработка pow: спецификация
Ещё до разработки мы можем представить себе, что эта функция будет делать, и описать это по методике BDD.
Это описание называется спецификация (или, как говорят в обиходе, «спека») и выглядит так:
У спецификации есть три основных строительных блока, которые вы видите в примере выше:
В названии блока it человеческим языком описывается, что должна делать функция, далее следует тест, который проверяет это.
Есть и другие виды сравнений и проверок, которые мы увидим далее.
Поток разработки
Как правило, поток разработки таков:
Разработка ведётся итеративно: один проход за другим, пока спецификация и реализация не будут завершены.
В нашем случае первый шаг уже завершён, начальная спецификация готова, хорошо бы приступить к реализации. Но перед этим проведём «нулевой» запуск спецификации, просто чтобы увидеть, что уже в таком виде, даже без реализации – тесты работают.
Пример в действии
Для запуска тестов нужны соответствующие JavaScript-библиотеки.
Мы будем использовать:
Эти библиотеки позволяют тестировать JS не только в браузере, но и на сервере Node.JS. Здесь мы рассмотрим браузерный вариант, серверный использует те же функции.
Пример HTML-страницы для тестов:
Эту страницу можно условно разделить на четыре части:
Сборка сделана исключительно для более компактного представления задач, без рекомендаций использовать именно её в проектах.
Как начать писать модульные тесты в JavaScript
Мы все знаем, что должны писать модульные тесты. Но трудно понять, с чего начать и сколько времени посвятить тестированию по сравнению с реальной реализацией. Итак, с чего начать? И это только о тестировании кода или у модульных тестов есть другие преимущества?
Различные виды тестирования
Прежде чем мы углубимся в специфику модульного тестирования, я хочу быстро пробежаться по различным типам тестов. Вокруг них часто возникает некоторая путаница, и я не удивляюсь. Иногда грань между ними довольно тонкая.
Модульные тесты
Модульные тесты тестируют только одну часть вашей реализации. Блок. Нет зависимостей или интеграций, нет специфики структуры. Они похожи на метод, который возвращает ссылку на определенном языке:
Интеграционные тесты
В какой-то момент ваш код связывается с базой данных, файловой системой или другой третьей стороной. Это может быть даже другой модуль в вашем приложении.
Эта часть реализации должна быть проверена интеграционными тестами. Обычно они имеют более сложную настройку, которая включает подготовку сред тестирования, инициализацию зависимостей и так далее.
Функциональные тесты
Модульные и интеграционные тесты дают вам уверенность в том, что ваше приложение работает. Функциональные тесты смотрят на приложение с точки зрения пользователя и проверяют, что система работает должным образом.
На диаграмме выше вы видите, что модульные тесты составляют большую базу набора тестов вашего приложения. Как правило, они маленькие, их много, и они выполняются автоматически.
Итак, теперь давайте углубимся в юнит-тесты.
Почему я должен беспокоиться о написании юнит-тестов?
Всякий раз, когда я спрашиваю разработчиков, пишут ли они тесты для своего приложения, они всегда говорят мне: «У меня не было на них времени» или «Мне они не нужны, я знаю, что это работает».
Быть уверенным, что ваш код работает. Когда в последний раз вы вносили изменения в код, сборка не удалась, и половина приложения перестала работать? А изменение было на прошлой неделе.
Но с этим все в порядке. Реальная проблема заключается в том, что когда сборка завершается успешно, изменения внедряются, и ваше приложение начинает работать нестабильно.
Когда это происходит, вы начинаете терять уверенность в своем коде и в конечном итоге просто молитесь, чтобы приложение работало. Модульные тесты помогут вам быстрее обнаружить проблемы и обрести уверенность.
Принимайте лучшие архитектурные решения. Изменения кода, некоторые решения о платформе, модулях, структуре и других должны быть приняты на ранних стадиях проекта.
Когда вы начнете думать о модульном тестировании с самого начала, это поможет вам лучше структурировать свой код и добиться правильного разделения задач. У вас не будет соблазна назначить несколько обязанностей отдельным блокам кода, так как это станет кошмаром для юнит-тестов.
Определить функциональность перед кодированием. Вы пишете сигнатуру метода и сразу начинаете его реализовывать. О, но что должно произойти, если параметр имеет значение null? Что если его значение находится за пределами ожидаемого диапазона или содержит слишком много символов? Вы бросаете исключение или возвращаете ноль?
Модульные тесты помогут вам обнаружить все эти случаи. Посмотрите снова на вопросы, и вы обнаружите, что именно это определяет ваши тесты.
Я уверен, что написание модульных тестов дает гораздо больше преимуществ. Это только те, которые я помню из моего опыта. Те, которые я выучил трудным путем.
Как написать свой первый модульный тест на JavaScript
Но вернемся к JavaScript. Мы начнем с Jest, который представляет собой среду тестирования JavaScript. Это инструмент, который обеспечивает автоматическое модульное тестирование, обеспечивает покрытие кода и позволяет легко макетировать объекты.
Давайте использовать ранее упомянутый метод getAboutUsLink в качестве реализации, которую мы хотим протестировать:
Теперь мы можем установить Jest CLI глобально и запустить тест:
Вы должны увидеть что-то вроде этого:
Прекрасная работа! Это был первый простой модульный тест JavaScript от начала до конца. Давайте попробуем, расширив тест этой строкой:
Как только вы сохраните файл, Jest сообщит вам, что тест не пройден. Это поможет вам обнаружить потенциальные проблемы еще до внесения изменений.
Тестирование расширенной функциональности и сервисов с Mocking
В реальной жизни языковые коды для метода getAboutUsLink не будут константами в одном и том же файле. Их значение обычно используется в проекте, поэтому они будут определены в своем собственном модуле и импортированы во все функции, которые их используют.
Вы можете импортировать эти константы в тест таким же образом. Но ситуация станет более сложной, если вы будете работать с объектами, а не с простыми константами. Взгляните на этот метод:
Этот метод использует импортированный UserStore :
Если бы мы не использовали Mock, мы бы протестировали и эту функцию, и хранилище. Это будет интеграционный тест, и нам, скорее всего, нужно будет смоделировать использованную базу данных.
Mock сервиса
Чтобы макетировать объекты, вы можете предоставить имитацию или ручной макет. Я остановлюсь на последнем, поскольку у меня есть простой и понятный вариант использования.
Модульный тест для функции getUserDisplayName похож на тот, который мы создали ранее:
Как только я сохраняю файл, Джест сообщает, что у меня есть 2 прохождения теста. Если вы выполняете тесты вручную, сделайте это сейчас и убедитесь, что вы видите тот же результат.
Отчет о покрытии кода
Покрытие кода скажет вам, насколько большая часть вашего кода покрыта модульными тестами. Возьмем для примера мой первый модульный тест, проверяющий функцию getAboutUsLink :
Чтобы увидеть отчет о покрытии кода, введите в терминал следующую команду:
Теперь я не должен упоминать, что вы должны стремиться к 100% охвату кода, верно? 🙂
Тестирование JavaScript кода с Jest для чайников. Часть 1
Что такое Jest?
Jest — это восхитительная среда тестирования JavaScript с упором на простоту.
И действительно, Jest очень простой. Он не требует дополнительных настроек, легкий в понимании и применении, а так же имеет довольно хорошую документацию. Отлично подходит для проектов использующих Node, React, Angular, Vue, Babel, TypeScript и не только.
Также он имеет открытый исходный код и поддерживается компанией Facebook.
Установка
Для установки Jest в ваш проект выполните:
Если вы используете yarn:
После установки можете обновить секцию scripts вашего package.json:
С помощью такого простого вызова мы уже можем запустить наши тесты (на самом деле jest потребует существование хотя бы одного теста).
Также можно установить глобально (но так делать я бы не рекомендовал, так как по мне глобальная установка модулей является плохой практикой):
И соответственно для yarn:
После этого вы можете использовать jest непосредственно из командной строки.
Первый тест
Давайте создадим файл first.test.js и напишем наш первый тест:
И запустим наши тесты с помощью npm run test или непосредственно командой jest (если он установлен глобально). После запуска мы увидим отчет о прохождении тестов.
Давайте «сломаем» наш тест и запустим jest повторно:
Как мы видим, теперь наш тест не проходит проверки. Jest отображает подробную информацию о том, где возникла проблема, какой был ожидаемый результат, и что мы получили вместо него.
Теперь давайте разберём код самого теста. Функция test используется для создания нового теста. Она принимает три аргумента (в примере мы использовали вызов с двумя аргументами). Первый — строка с названием теста, его jest отобразит в отчете. Второй — функция, которая содержит логику нашего теста. Также можно использовать 3-й аргумент — таймаут. Он является не обязательным, а его значение по умолчанию составляет 5 секунд. Задаётся в миллисекундах. Этот параметр необходим когда мы работаем с асинхронным кодом и возвращаем из функции теста промис. Он указывает как долго jest должен ждать разрешения промиса. По истечению этого времени, если промис не был разрешен — jest будет считать тест не пройденным. Подробнее про работу с асинхронными вызовами будет в следующих частях. Также вместо test() можно использовать it(). Разницы между такими вызовами нету. it() это просто алиас на функцию test().
Внутри функции теста мы сначала вызываем expect(). Ему мы передаем значение, которое хотим проверить. В нашем случае, это результат вызова Math.max(1, 5, 10). expect() возвращает объект «обертку», у которой есть ряд методов для сопоставления полученного значения с ожидаемым. Один из таких методов мы и использовали — toBe.
Давайте разберем основные из этих методов:
Давайте напишем пару простых тестов. Для начала создадим простой модуль, который будет содержать несколько методов для работы с окружностями.
Далее добавим тесты:
В этих тестах мы проверили результат работы 2-х методов — area и circumference. При помощи метода toBeCloseTo мы сверились с ожидаемым результатом. В первом случае мы проверили или вычисляемая площадь круга с радиусом 5 приблизительно равна 78.54, при этом разница с полученым значением (оно составит 78.53981633974483) не большая и тест будет засчитан. Во втором мы указали, что нас интересует проверка с точностью до 1 знака после запятой. Также мы вызвали наши методы без аргументов и проверили результат с помощью toBeNaN. Поскольку результат их выполнения будет NaN, то и тесты будут пройдены успешно.
Разберём ещё один пример. Создадим функцию, которая будет фильтровать массив продуктов по цене:
В этом тесте мы проверям результат работы функии byRangePrice. Сначала мы проверили соответствие длины полученого массива ожидаемой — 2. Следующая проверка требует, чтобы в массиве находился элемент — < name: 'tomato', price: 26 >. Объект в массиве и объект переданный toContainEqual — это два разных объекта, а не ссылка на один и тот же. Но toContainEqual сверит каждое свойство. Так как оба объекта идентичные — проверка пройдет успешно. Далее мы используем toEqual для провеки структуры всего массива и его элементов. Методы toBeGreaterThanOrEqual и toBeLessThanOrEqual помогут нам проверить price первого и второго элемента массива. И, наконец, вызов not.toContainEqual сделает проверку, не содержится ли в массиве элемент — < name: 'orange', price: 38 >, которого по условию там быть не должно.
В данных примерах мы написали несколько простых тестов используя функции проверки описанные выше. В следующих частях мы разберём работу с асинхронным кодом, функции jest которые не затрагивались в этой части туториала, поговорим о его настройке и многое другое.
Как создавать тесты и викторины на JavaScript
Разбираемся, как создавать тесты и викторины для сайта на ванильном JavaScript.
Тесты и викторины хороши не только ради проверки знаний, но и как развлекательный контент, который заставляет пользователей дольше оставаться на сайте.
Чтобы их создать, можно воспользоваться сторонними сервисами, но разве это когда-нибудь останавливало хоть одного разработчика? С любовью изобретать велосипеды мы создадим собственный код для встраивания тестов на страницы.
Репозиторий проекта на GitHub
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Вёрстка страницы
Тест мы поместим в файл quiz.html, чтобы его можно было вставлять с помощью iframe в другие страницы. Давайте сверстаем тест:
Теперь добавим стили:
В файл index.html добавим iframe, чтобы подключить тест:
Смотрим, что получилось:
Наверху находится сам вопрос, под ним — варианты ответов, а в самом низу — прогресс прохождения теста.
Создаём классы
Тест будет работать с помощью следующих классов:
Когда классы готовы, можно инстанцировать объекты (создавать экземпляры):
Здесь создан только один вопрос, чтобы не отвлекать повторяющимся кодом. Вы можете добавить их столько, сколько вам необходимо.
Остаётся только прописать логику взаимодействия с пользователем:
Смотрим, что получилось:
Когда пользователь завершит тест, то увидит свой результат:
Особенности создания разных тестов
Как вы могли заметить, это очень простой тест. Он пригодится, чтобы пользователи могли проверить, насколько хорошо они усвоили материал. Ну или просто для веселья — вот несколько тем для развлекательных тестов:
Всё это может быть очень забавным и вовлекающим, если учитывать особенности своей аудитории. Например, для программистов есть интересные тесты на сайте tproger.ru.
Другое дело, если у вас образовательная платформа и результаты теста влияют на итоговую оценку. В этом случае данные о правильных ответах нужно хранить на сервере. Иначе их можно подсмотреть через консоль разработчика:
То же самое касается и таймеров: если вы даёте ограниченное время на прохождение теста, то время начала отсчёта должно храниться на сервере, а не в JS-коде.
Заключение
С помощью кода из статьи можно создавать сколько угодно тестов. Разве что для каждого придётся дублировать файл app.js, чтобы указать новые вопросы.
Исправить это можно с помощью HTTP-запросов — вопросы будут храниться на сервере и отправляться пользователю в виде JSON. Это очень распространённая практика в веб-разработке, которую нужно знать каждому разработчику.
Если вы хотите лучше освоить JavaScript, то можете записаться на наш курс по Frontend-разработке.
Учимся тестировать JavaScript код
Тестирование кода – неотъемлемый цикл разработки программного обеспечения. Начинающие команды девелоперов зачастую недооценивают его роль и проверяют работоспособность приложения по старинке – «работает, да и ладно». Рано или поздно эта стратегия дает сбой и баг-трекер начинает захлестывать бесчисленная армия тасков. Чтоб не угодить в подобную западню, рекомендую раз и навсегда разобраться с нюансами тестирования JavaScript кода.
JavaScript уже не тот
Сегодня JavaScript – это не просто язык для оживления внешнего вида приложения. Времена, когда JavaScript использовали для шуток или изготовления менюшек безвозвратно прошли. Теперь это самостоятельный язык, который одинаково хорошо работает как на клиенте, так и на сервере. Роль JavaScript существенно повысилась, а значит, при написании кода нужно не стесняться пользоваться хорошо зарекомендовавшими себя в других языках программирования практиками.
Что я подразумеваю под практиками и парадигмами? Конечно же, архитектурный шаблон MVC (model view controller) и паттерны организации кода. Следуя этим не хитрым премудростям, ты сможешь писать более качественный код, который будет не только легко сопровождаться, но обладать способностью к автоматическому тестированию.
Ошибка большинства тестеров
На практике же все происходит несколько иначе. Отдельного тестировщика, как правило, нет. Разработчик сам пытается проверить работоспособность программы, выполняя определенную в техническом задании последовательность действий. Более продвинутые кузницы кода, автоматизируют подобное интеграционное тестирование при помощи вещей вроде Selenium.
Таким образом, программист получает возможность обнаружить лишь самые грубые ошибки. К сожалению, «тупые» и «непредусмотренные» пользовательские действия, а также хитрые ходы в бизнес логике, в 99% случаев остаются за кадром.
Наличие отдельного человека в лице тестировщика решает проблему тоже частично и до определенного времени. Даже если отбросить его саперскую внимательность к деталям, то качество его тестирования будет стремиться к нулю с ростом приложения. Приведу пример из практики.
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 выполняется достаточно просто. Последний пример, который мне хотелось бы разобрать, связан с написанием теста, выполняющий несколько асинхронных проверок. Главный вопрос, который возникает на этом в подобных задачах – оптимальное место для старта потока выполнения. Официальный док предлагает применять в этих случаях что-то вроде:
Тест для пользовательских действий
Всегда надо помнить, что на JavaScript пишется очень много всяких интерфейсных штук. Например, пользователь кликает по пимпе и в ответ на его клик должно что-то произойти. Подобного «интерфейсного» кода в проектах огромное количество и его также необходимо покрывать тестами. Давай посмотрим, как можно смоделировать пользовательское нажатие клавиши и написать для этого действия отдельный тест. Представим, что у нас есть некая функция, которая логирует нажатые клавиши. Ее код я привел в третьем листинге:
Листинг 3. Логирование нажатых клавиш
Теперь попробуем эту функцию протестировать. Первым делом, в теле теста нам необходимо эмулировать нажатую клавишу. Проще всего это сделать при помощи библиотеки jQuery, которая позволяет создать событие в пару строчек кода (см. листинг 4).
Листинг 4. Код теста для KeyLogger
В самом начале листинга с тестом я подготавливаю событие для эмуляции нажатия клавиши – «keydown». Нас будет интересовать нажатие клавиши Tab (код 9). Затем, при помощи метода trigger() я отправляю приготовленное событие, после чего можно приступать к тестированию. Сначала проверяем общую картину – была ли нажата клавиша, а затем, ее код.
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() из примеров в статье), лучше сосредоточить на наиболее критичных участках кода. Придерживаться этого же правила следует при написании часто изменяемого кода. Техническое задание живого проекта частенько меняется, и некоторые функции приходится постоянно обновлять. Такие перемены могут повлечь за собой неприятные моменты – с новыми данными измененный код работает хорошо, а старые органически не переваривает. Вот чтобы не поймать здесь фейл, подобные функции лучше сразу покрыть тестами. Запомни простое правило – нет времени покрыть весь код тестами, покрой самую важную его часть.