12 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Не забывайте про тестирование на стороне клиента

Содержание

Не забывайте про тестирование на стороне клиента!

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

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

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

  • Зачем нужны тесты в принципе?
  • TDD – это процесс исследования кода
  • Тестирование на стороне клиента
  • Приступим к работе
    • Выбор библиотеки для тестирования
    • TDD с помощью QUnit
    • Псевдо зависимости с помощью Sinon.js
    • Диапазон охвата теста
    • Сложные тесты
  • Заключение

Модульные тесты и интеграционные: в чём разница?

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

Ниже представлен интеграционный тест для небольшой части поискового приложения:

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

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

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

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

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

«Обычное» JavaScript приложение может выглядеть так:

Мой друг Адама Сонтега (Adam Sontag) называет это «Выбери себе приключение сам» — в каждой строчке мы с равной вероятностью можем иметь дело как с представлением, так и с информацией, обслуживанием логики пользовательского взаимодействия или проверкой состояния приложения. Остаётся только догадываться! Достаточно просто написать интеграционные тесты для этого кода, и в тоже время очень сложно написать тесты для тестирования отдельных функциональных частей приложения.

Почему это сложно? На это существуют четыре причины:

  • общий недостаток структурированности; чаще всего всё происходит в коллбэке $(document).ready() — и, так как это анонимная функция, её невозможно протестировать ввиду невозможного к ней обращения;
  • слишком сложные функции; Если в функции больше 10 строк кода, как в обработчике отправки формы, то эта функция, вероятно, выполняет и несёт отвественность за слишком много вещей;
  • скрытые состояния; так как состояние pending помещено в замыкание, то нет никакой возможности проверить, правильно ли установлено это состояние;
  • избыточная связанность функционала; к примеру, обработчику $.ajax совершенно нет необходимости иметь доступ к DOM;

yolpo

Это больше не существует, вместо этого перенаправляет на sequential.js

Yolpo — это инструмент для визуализации выполнения javascript. Разработчикам Javascript API предлагается написать свои сценарии использования, чтобы показать и рассказать об их API. Такие варианты использования составляют основу регрессионных тестов.

Футуристический тестовый бегун со встроенной поддержкой ES2015. Несмотря на то, что JavaScript является однопоточным, IO в Node.js может происходить параллельно из-за его асинхронной природы. AVA использует это и выполняет ваши тесты одновременно, что особенно полезно для тяжелых тестов ввода-вывода. Кроме того, тестовые файлы запускаются параллельно как отдельные процессы, обеспечивая еще лучшую производительность и изолированную среду для каждого тестового файла.

  • Минимальный и быстрый
  • Простой тестовый синтаксис
  • Запускает тесты одновременно
  • Обеспечивает написание атомных тестов
  • Нет скрытых глобалов
  • Изолированная среда для каждого тестового файла
  • Напишите свои тесты в ES2015
  • Обещание поддержки
  • Поддержка функции генератора
  • Поддержка асинхронных функций
  • Наблюдаемая поддержка
  • Расширенные утверждения
  • Дополнительный TAP o utput
  • Чистые следы стека

5 последних уроков рубрики «jQuery»

Анимация набора текста на jQuery

Сегодня мы бы хотели вам рассказать о библиотеке TypeIt — бесплатном jQuery плагине. С её помощью можно имитировать набор текста. Если всё настроить правильно, то можно добиться очень реалистичного эффекта.

Временная шкала на jQuery

jQuery плагин для создания временной шкалы.

Заметка: Перезагрузка и редирект на JavaScript

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

Рисуем диаграмму Ганта

jQuery плагин для создания диаграммы Ганта.

AJAX и PHP: загрузка файла

Пример того как осуществить загрузку файла через PHP и jQuery ajax.

QUnit. Тестирование javascript кода

Наткнулся вчера на этот инструмент и не смог пройти мимо, провел ночь за написанием тестов, а теперь хочу поделиться находкой. QUnit — это библиотека от разработчиков jQuery, позволяющая писать unit-тесты для кода на javascript. Удобна в использовании, ничего лишнего, осваивается за 20 минут, выгода от применения — колоссальная.

Самым нетерпеливым сразу ссылки:
Официальная документация на сайте jquery: docs.jquery.com/QUnit
Реальные примеры тестов (для модулей jquery): view.jquery.com/trunk/jquery/test/unit
Руководство для начинающих (англ): www.swift-lizard.com/2009/11/24/test-driven-development-with-jquery-qunit
Система распределенного тестирования (гениально и просто): testswarm.com

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

Зачем писать unit-тесты?

Представим себе обычный цикл разработки: получили задачу, решили её, протестировали, починили баги и выпустили версию. Затем получили баг-репорты и фиче-реквесты и приступили к новому циклу разработки. По завершению этого цикла нам снова надо будет проверить, что всё то, что было реализовано ранее, по прежнему работает — провести регрессионное тестирование. И проводить его надо будет для каждого нового цикла разработки. По мере разрастания проекта на это будет уходить всё больше и больше времени. А как происходит регрессионное тестирование в web-проектах? Кликаем мышкой по кнопкам и ссылкам. В каждом браузере, для каждой фичи, на каждом цикле разработки. Нашли баг, поправили, обновляем страницу и снова кликаем, кликаем, кликаем.

Читать еще:  Вконтакте версия 4.8 3 скачать для андроид. ВКонтакте на андроид. Почему стоит скачать ВКонтакте на андроид

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

Касательно web-разработки есть ещё одно огромное преимущество — запуск тестов под разными платформами и браузерами. Больше нет нужды проверять дотошно, как этот кусок кода будет работать в msie, понравится ли он опере, а как к нему отнесется сафари. Достаточно написать тест, который проверит функциональность. Более того, эту работу можно распределить между обычными пользователями, хороший пример такой функциональности — testswarm.com.

Как использовать QUnit

DOCTYPE HTML PUBLIC «-//W3C//DTD HTML 4.01 Transitional//EN»
«http://www.w3.org/TR/html4/loose.dtd» >
html >
head >
link rel =»stylesheet» href =»qunit.css» type =»text/css» media =»screen» >
script type =»text/javascript» src =»qunit.js» > script >

script >
head >
body >
h1 id =»qunit-header» > QUnit test env h1 >
h2 id =»qunit-banner» > h2 >
h2 id =»qunit-userAgent» > h2 >
ol id =»qunit-tests» >
ol >
body >
html >

* This source code was highlighted with Source Code Highlighter .

Теперь подключаем свой код и можно писать тесты.

Как писать тесты

* This source code was highlighted with Source Code Highlighter .

А вот так её можно протестировать:

test( ‘trim()’ , function () <
equals(trim( » ), » , ‘Пустая строка’ );
ok(trim( ‘ ‘ ) === » , ‘Строка из пробельных символов’ );
same(trim(), » , ‘Без параметра’ );

equals(trim( ‘ x’ ), ‘x’ , ‘Начальные пробелы’ );
equals(trim( ‘x ‘ ), ‘x’ , ‘Концевые пробелы’ );
equals(trim( ‘ x ‘ ), ‘x’ , ‘Пробелы с обоих концов’ );
equals(trim( ‘ x ‘ ), ‘x’ , ‘Табы’ );
equals(trim( ‘ x y ‘ ), ‘x y’ , ‘Табы и пробелы внутри строки не трогаем’ );
>);

* This source code was highlighted with Source Code Highlighter .

Разберем пример построчно. В первой строке вызов функции test. Первым параметром обозначаем функционал который тестируем. Последним — тестирующую функцию. Внутри этой функции производятся различные проверки. В данном случае мы проверяем соответствие результата выполнения функции и ожидаемой строки. Для проверки на соответствие используются функции:

  • equals — проверяет равенство первых двух параметров (нестрогая проверка, только для скалярных величин)
  • ok — истинность первого параметра
  • same — строгая проверка на равенство первых двух параметров (проверяет также равенство двух массивов и объектов)

Последним параметром функции принимают описание тестового случая.
В результате этой проверки получаем следующую картину:

Все тесты пройдены.

Как протестировать ajax? Асинхронные проверки.

С синхронными функциями просто. А что с асинхронными? Очевидно, для асинхронности мы должны остановить нормальный поток управления и по окончанию теста возобновить его. Этому служат функции stop() и start(). Вот простой пример:

test( ‘async’ , function () <
// Останавливаем поток выполнения на этом тесте
stop();

setTimeout( function () <
ok( true );

// По завершению теста
// возобновляем работу тестировщика
start();
>, 500);
>);

* This source code was highlighted with Source Code Highlighter .

Чтобы не вызывать всякий раз stop(); предусмотрен следующий вариант функции:

asyncTest( ‘async’ , function () <
// поток остановлен автоматически

setTimeout( function () <
ok( true );

// Возобновляем конечно же вручную
start();
>, 500);
>);

* This source code was highlighted with Source Code Highlighter .

А что если надо вызвать несколько асинхронных проверок в одном тесте? Когда в этом случае «стартовать» поток? Решение предлагается такое:

asyncTest( ‘asynctest’ , function () <
// Pause the test
expect(3);

$.get( function () <
// асинхронные проверки
ok( true );
>);

$.get( function () <
// другие асинхронные проверки
ok( true );
ok( true );
>);

setTimeout( function () <
start();
>, 2000);
>);

* This source code was highlighted with Source Code Highlighter .

Поток стартуется через 2 секунды. За это время должны пройти три проверки (вызов expect сообщает об этом тестирующей программе). Кстати, вместо вызова expect можно передавать второй числовой параметр функции test (asyncTest). Поведение будет идентичным предыдущему примеру.

Группировка тестов по модулям

QUnit позволяет сгруппировать тесты по модулям. Для этого достаточно вызвать функцию module(‘Название модуля или группы тестов’) непосредственно перед вызовом тестов. Это удобно.

F.I.R.S.T

F.I.R.S.T. — методология описания требованиий, которым должны отвечать тесты. Прежде всего, модульные, но в принципе эти характеристики можно экстраполировать и на автоматические тесты. Ее создатель — известный дядюшка Боб — автор многих практик программирования.

  • Быстрота (Fast). Тесты должны быть быстрыми, медленные тесты никто не станет запускать. На их проведение не хватит времени даже у команды из 30 тестировщиков.
  • Независимость (Independent). Тесты должны быть независимы: ни один элемент не может зависеть от исполнения предыдущего.
  • Повторяемость (Repeatable). Вы должны иметь возможность запустить любой тест в любой момент, и его поведение должно быть предсказуемо.
  • Очевидность (Self-Validating). Поведение теста должно быть очевидно, прежде всего для тех, кто создает программу.
  • Своевременность (Timely). Тесты должны быть написаны тогда, когда они действительно нужны.

Рис. 5. Схема TDD-процесса.

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

Тестирование javascript кода. Как протестировать код Javascript с помощью QUnit. Зачем следует тестировать свой код

Мысли Криса Койера

Одна из мыслей, которая поселилась в моей голове: должен ли frontend-разработчик быть в курсе всего? В общем смысле, frontend-разработчик может использоваться и на других рабочих местах. Вся команда разработчиков заканчивает разговор на frontend-разработчике. В этом смысл моей идеи. Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. Возможно, именно поэтому это такая забавная работа! Поскольку frontend-разработчик занимает центральное место в цепочке разработки, и при этом мы имеем дело с большим количеством разных специалистов, мы должны понимать их работу и иногда подсказывать, что и как сделать лучше.

От переводчика

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

Frontend-разработчик должен разбираться в дизайне

Если frontend-разработчик не является сам по себе дизайнером, он должен знать, насколько важен дизайн. Он должен иметь хороший вкус. Он должен знать об инструментах, участвующих непосредственно в разработке.

Читать еще:  Стоит ли покупать маленький (мини) компьютер?

К прочтению:

Frontend-разработчик должен разбираться в работе серверной части (backend)

Даже если вы и не backend-разработчик, то вы явно осознаёте всю важность серверной части. Вы понимаете, с чем взаимодействует backend, что передается на сервер, а что нет. Вы знаете об обязанностях backend-разработчика. Вы понимаете, какой язык используется на сервере, и при этом должны уметь объяснить, что должен дать вам backend и что нужно от серверной части frontend-а.

К прочтению:

Frontend-разработчик должен разбираться в работе сетей

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

К прочтению:

Frontend-разработчик должен разбираться в производительности

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

К прочтению:

Frontend-разработчик должен разбираться в контент-стратегии

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

К прочтению:

Frontend-разработчик должен разбираться в базах данных

Контент хранится в базе данных. База данных должна корректно работать с контентом. А frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных. Frontend-разработчику при работе с ответом базы данных нужно уметь комбинировать контент с шаблонами на сайте.

К прочтению:

Frontend-разработчик должен разбираться в тестировании

Существует большое количество видов тестирования. Интеграционное тестирование. Регрессионное тестирование. Пользовательское тестирование!

К прочтению:

Frontend-разработчик должен разбираться в системах сборки

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

К прочтению:

Frontend-разработчик должен разбираться в методологиях разработки

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

К прочтению:

Frontend-разработчик должен разбираться в настройке веб-серверов

Без них не было бы веб-сайтов.

К прочтению:

Frontend-разработчик должен разбираться в юзабилити

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

К прочтению:

Frontend-разработчик должен разбираться в мобильном дизайне

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

К прочтению:

Заключение

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

Введение в unit тестирование JavaScript кода

Привет, сегодня поговорим про unit тестирование javascript, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое unit тестирование javascript , настоятельно рекомендую прочитать все из категории Выполнение скриптов на стороне клиента JavaScript, jqvery, JS фреймворки

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

Обычно такая ситуация происходит, когда разработчик для написания приложения не использует специальные JavaScript библиотеки. Еще бы, ведь написать встроенный обработчик события намного легче, чем привязать его же через DOM API. Однако большинство разработчиков все же используют специальные JavaScript библиотеки, например JQuery. JQuery позволяет помещать встроенные обработчики в отдельные сценарии или на той же странице, или в отдельном js файле. Но код, размещенный в отдельном файле, не является готовым к тестированию модулем.

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

Создание модульных тестов

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

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

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

Достаточно теориии! Разберу-ка я практический пример, тестируя конкретный JavaScript код, который встроен в html код страницы. Скрипт просматривает все ссылки с аттрибутом title. И использует значение этого аттрибута для преобразования текста ссылок в более человеческий вид: «n minutes ago», «n hours ago», «n weeks ago».

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

Преобразование кода в тестируемый вид

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

В результате работы скрипта, появились ссылки: «2 часа назад», «вчера» и так далее . Об этом говорит сайт https://intellect.icu . Это уже кое-что, но до тестируемого модуля не дотягивает. Поэтому, без дальнейшего рефакторинга все, что я могу делать, это протестировать изменения в разметке.

При этом нужно создавать код с максимально чисто функцией (методами) , для того чтобы тесты былиь изолированы от окружения (БД, сеть, файловая система, время).

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

По всей видимости скрипт нуждается в 2 изменениях:

  • Передача даты в функцию prettyDate (что уже сделано);
  • Выделение функции prettyDate в отдельный файл, чтобы его можно было подключить в страницу для модульного тестирования.
Читать еще:  ТОП-12 Самых Лучших Селфи-Палок

Теперь можно писать модульный тест.

(Перед запуском убедитесь, что у вас включена консоль, например Firebug или Chrome’s Web Inspector.)

В результате получился модульный тест, который выводит результаты в консоль. Это позволяет избежать зависимости от DOM, поэтому тест можно запустить в небраузерной JavaScript среде, например Node.js или Rhino.

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

При успешном прохождении всех тестов, результат будет следующего вида:

Если один из тестов не прошел, то он выведен в консоль в таком виде:

Expected 2 day ago, but was 2 days ago.
Of 6 tests, 1 failed, 5 passed.

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

Среда QUnit для тестирования JavaScript кода

Выбор фреймворка для тестирования является делом вкуса.

Я предпочитаю использовать QUnit, потому что у него много возможностей

Здесь стоит обратить внимание на 3 секции. Здесь подключены 3 файла: 2 файла это QUnit (qunit.css and qunit.js) и 1 файл prettydate.js.

Затем идет блок JavaScript кода с тестовыми данными. Метод test вызывается только один раз, передавая в качестве первого аргумента имя теста, а вторым аргментом является функция, которая фактически запускает тесты. В этом блоке объявляется переменная now, которая используется при вызове метода equal. Метод equal — это один из методов, которые предлагает QUnit. В качестве первого аргумента методу equal передается результат функции prettyDate. В качестве второго аргумента методу equal передается ожидаемый результат. Если эти два аргумента будут одинаковыми, то утверждение истинно, иначе не истинно.

При успешном тесте QUnit выведет результат следующего вида:

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

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

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

Тестовых данных недостаточно, т.к. я не тестирую вариант n weeks ago. Но сначала я снова сделаю рефакторинг. Функция prettyDate вызывается для каждого утверждения и каждый раз передается аргумент now. Сейчас я это исправлю:

Теперь функция prettyDate вызывается внутри новой функции date и больше не создается переменная now, ее значение жестко прописано в качестве параметра.

Тестирование операций с DOM деревом

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

Из базового скрипта я выделил новую функцию prettyDate.update, однако аргумент now все еще передается в prettyDate.format. Базовый QUnit-тест для этой функции начинается с отбора всех элементов a из блока div с идентификатором #qunit-fixture. В HTML коде появился новый элемент

. В нем содержится извлеченная разметка из начального примера, необходимая для тестирования. Помести ее в #qunit-fixture можно не беспокоиться о влиянии одного теста на результат другого, т.к. QUnit автоматически сбрасывает разметку после каждого теста.

Что происходит при первом тестировании prettyDate.update.

Сначала выбираются ссылки из

, далее они проверяются на содержание дат. Затем вызывается prettyDate.update, передавая фиксированную дату (такую же как и в предыдущих тестах). Потом происходит проверка текста этих же ссылок на желаемые значения «2 hours ago» и «Yesterday», т.к. prettyDate.update должен был заменить этот текст.

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

Следующий тест prettyDate.update, one day later делает почти тоже самое, за исключением того, что передает другую дату в prettyDate.update и потому возвращает другой результат для 2 ссылок.

Настало время для очередного рефакторинга! Необходимо убрать дублирование!

В этом примере я создал новую функцию domtest, которая инкапсулирует логику двух предыдущих вызовов для проверки и передает такие аргументы как имя теста, дату в строковом формате и две ожидаемые на выходе строки. Эта функция вызывается дважды.

Что произошло?

Надо бы посмотреть, что получилось в итоге)

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

Заключение

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

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

Понравилась статья о unit тестирование javascript? Откомментируйте её Надеюсь, что теперь ты понял что такое unit тестирование javascript и для чего все это нужно, а если не понял, или есть замечания, то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятелно рекомендую изучить комплексно всю информацию в категории Выполнение скриптов на стороне клиента JavaScript, jqvery, JS фреймворки

3 js-фреймворка на личном опыте

Знакомство 1

Первый, с кем я познакомилась из фреймворков, был Backbone.js. Backbone.js может похвастаться внушительным списокомприложений, использующих фреймворк, и кучей примочек вроде Backbone.Marionette, Backbone.ViewMasterи Backbone.stickit. Хотя такие примочки являются своего рода знаком, что какие-то вещи фреймворк не решает или решает плохо. В упакованном виде Backbone.js весит всего 6.3Кб, а единственная жесткая зависимость — это Underscore.js. Но если хочется использовать всю мощь Backbone.Router и иметь возможность манипулировать с DOM в Backbone.View, то без json2.js и jQuery (или Zepto) не обойтись. Backbone сразу же поразил меня своим мощным Backbone.Router, моделями и коллекциями. Я была неопытная, впечатлительная, он был моим первым javascript mv*-фреймворком.
Я могла описать модель данных (Backbone.Model)

//backbone.js
var FrameworkModel = Backbone.Model.extend( <
defaults: <
«title»: «»,
«url»: «»,
«shortDescription» : «»
>
>);
сделать на её основе коллекцию
//backbone.js
var FrameworkCollection = Backbone.Collection.extend( <
model: FrameworkModel
>);
показать html-шаблон элемента (Backbone.View)
//backbone.js
var FrameworkView = Backbone.View.extend( <
tagName: «div», //тэг элемента
className: «line», //css-класс для тэга
template: $(«#itemTemplate»).html(), //html шаблонного div’a

render: function() <
var templ = _.template(this.template);
this.$el.html(templ(this.model.toJSON()));
return this;
>
>);
//html скелет

и легко получить отображение всей коллекции:

Знакомство 2

Знакомство 3

a scope can be seen as the glue which allows the template, model and controller to work together. Angular uses scopes, along with the information contained in the template, data model, and controller, to keep models and views separate, but in sync.

Any changes made to the model are reflected in the view; any changes that occur in the view are reflected in the model.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector