ilyachalov (ilyachalov) wrote,
ilyachalov
ilyachalov

Category:

JavaScript: умная подсказка, подключение автоматических тестов

Начало: JavaScript: умная подсказка, разбор постановки задачи.

Продолжаю разбирать задачу «"Умная" подсказка» к подразделу 3.2 «Движение мыши: mouseover/out, mouseenter/leave» второй части учебника по JavaScript.

* * *

Авторы задачи написали в песочнице тестовую HTML-страницу, на которую вставлен скрипт на языке JavaScript, который нужен для запуска демонстрационного примера с умной подсказкой. Понятно, что пока мы не допишем класс HoverIntent (это будет являться решением данной задачи), расположенный в отдельном файле hoverIntent.js, умная подсказка на тестовой HTML-странице работать не будет. Вот этот скрипт:
// для демо
setTimeout(function() {
  new HoverIntent({
    elem,
    over() {
      tooltip.hidden = false;
    },
    out() {
      tooltip.hidden = true;
    }
  });
}, 2000);

Здесь создается новый объект класса HoverIntent, в результате чего HTML-элементу с идентификатором elem (в браузере он выглядит как часы) придается способность показывать умную подсказку, которую изображает HTML-элемент с идентификатором tooltip.

У меня сразу возник вопрос: а зачем здесь используется функция setTimeout, отодвигающая создание нового объекта класса HoverIntent на 2000 миллисекунд от начала запуска скрипта?

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

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

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

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

* * *

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

Заголовочная часть тестовой HTML-страницы выглядит так:
<head>
  <meta charset="UTF-8">
  <title>Документ</title>
  <link rel="stylesheet" href="style.css">
  <script src="hoverIntent.js"></script>
  <script src="https://js.cx/test/libs.js"></script>
  <script src="test.js"></script>
</head>

Как видно из этого кода, для работы тестовой HTML-страницы нужны четыре других файла. Рассмотрим их сверху вниз. В файле style.css описаны на языке CSS стили для тестовой HTML-страницы. В файле hoverIntent.js описан на языке JavaScript класс HoverIntent, который от нас требуется дописать, что и будет являться решением задачи.

В файле libs.js (слово «libs» по-русски означает «библиотеки»), можно сказать, описан «движок» для написания тестов. Этот файл написан на языке JavaScript и в нем происходит подключение сразу нескольких библиотек: собственно, фреймворка «Mocha» (сайт проекта: mochajs.org), библиотеки «Chai» (сайт проекта: chaijs.com), библиотеки «Sinon» (сайт проекта: sinonjs.org). Также там выполняются некоторые дополнительные настройки. Некоторые подробности про эти библиотеки и автоматическое тестирование можно узнать в подразделе 3.5 «Автоматическое тестирование c использованием фреймворка Mocha» первой части обсуждаемого учебника.

В файле test.js на языке JavaScript описаны пять тестов, которые тестируют объект класса HoverIntent, создаваемый в этом же файле.

Файлы style.css, hoverIntent.js и test.js я тоже скопировал на локальный веб-сервер, к уже имеющейся там тестовой HTML-странице index.html.

Файл libs.js я копировать на локальный веб-сервер не стал, он будет подгружаться из того же адреса, откуда он подгружается в песочнице, то есть из https://js.cx/test/libs.js.

После описанных манипуляций я открыл тестовую HTML-страницу index.html в браузере с локального веб-сервера, то есть по адресу:
http://localhost/index.html

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

Тут стоит отметить два момента.

Во-первых, скрипт с «движком» автоматических тестов libs.js добавляет на тестовую HTML-страницу свои стили.

Почему это происходит? Эти стили, в принципе, предназначены для придания приятного внешнего вида результатам автоматических тестов, которые появляются на HTML-странице, приготовленной для их отображения. Предполагается, что программист создал на HTML-странице отдельный HTML-элемент, внутрь которого будут выведены результаты тестов. К примеру, это может быть HTML-элемент div. У этого HTML-элемента должен быть идентификатор mocha. Если же такого HTML-элемента на HTML-странице нет (наш случай), то скрипт libs.js добавляет идентификатор mocha к HTML-элементу body, то есть ко всему телу HTML-страницы. В этом случае добавленные стили применяются (наследуются) ко всем HTML-элементам внутри тела HTML-страницы, в том числе к нашему тестовому HTML-элементу div, изображающему часы.

Это можно легко увидеть с помощью инструмента разработчика «Elements» (F12). Изначально ни в файле index.html, ни в файле style.css не определен шрифт для HTML-элемента div, изображающего часы. Следовательно, шрифт цифр в часах должен быть шрифтом, определенным в настройках браузера как шрифт по умолчанию, в моем браузере это «Times New Roman» размером 16px. Однако, после загрузки файла libs.js цифры часов в браузере отображаются шрифтом «Arial» размером 20px в соответствии с указанием font: 20px/1.5 "Helvetica Neue", Helvetica, Arial, sans-serif; из добавленного стиля. Из-за этого размер часов (то есть HTML-элемента div, их изображающего) стал гораздо больше.

Если на HTML-страницу в том месте, где желательно появление результатов автоматического тестирования, добавить, например, следующий HTML-элемент:
<div id="mocha"></div>
то результаты тестирования будут вписаны в этот HTML-элемент и добавленный стиль будет действовать только внутри этого HTML-элемента, как и было задумано, думаю, авторами фреймворка «Mocha».

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

Во-вторых, хоть автоматические тесты уже работают без проблем, но в консоль разработчика выводится предупреждение:
DevTools failed to load source map: Could not load content for http://localhost/mocha.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
то есть браузер почему-то ищет и не может найти на локальном веб-сервере файл mocha.min.css.map.

Что это за файл? Как видно из текста предупреждения, такие файлы (они имеют расширение .map) по-английски называются «source map», что на русский можно перевести как «карта исходного кода».

Зачем нужна карта исходного кода (source map)? Например, разработчик пишет файл стилей mocha.css на языке CSS, затем подвергает его минификации (уменьшению исходного кода путем удаления ненужных символов без изменения его функциональности, см. подробнее в википедии) и в результате получает другой файл — mocha.min.css (составление имени файла, полученного в результате минификации, из имени исходного файла добавлением вставки .min используется многими программами-минификаторами, насколько я знаю).

Файл mocha.min.css гораздо меньше по размерам исходного mocha.css, а делает то же самое, поэтому файл mocha.min.css загружают на рабочий сервер в действующий проект. Однако, что делать, если в файле mocha.min.css обнаружена ошибка? Отладчик покажет эту ошибку в файле mocha.min.css, а нужно, чтобы он показал ошибку в первоначальном файле mocha.css, так как разработчик работает с ним и ошибку будет исправлять в нем.

На этот случай и существует файл с картой исходного кода (source map), этот файл содержит связи между файлом mocha.min.css и файлом mocha.css. Благодаря карте исходного кода отладчик сможет автоматически показать по месту ошибки в файле mocha.min.css место той же ошибки в первоначальном файле mocha.css. Я так это понял.

Почему браузер показал это предупреждение, ведь у нас нет ни файла mocha.css, ни файла mocha.min.css? Я просмотрел скрипт libs.js и заметил, что в него включен текст со стилями, который позже добавляется на нашу тестовую HTML-страницу. Вероятно, это и есть текст файла mocha.min.css. А в этом тексте есть комментарий специального вида:
/*# sourceMappingURL=mocha.min.css.map */
Это один из двух способов подгрузки файла с картой исходного кода (source map).

В принципе, нам этот файл вообще не нужен, потому что мы занимаемся не отладкой кода фреймворка «Mocha», а отладкой (тестированием) своего собственного кода. Файл libs.js я изменять не захотел, поэтому решил добавить файл mocha.min.css.map на свой локальный веб-сервер.

Файл карты исходного кода не может быть пустым файлом с названием mocha.min.css.map, потому что по стандарту для таких карт этот файл должен содержать объект, в котором есть четыре обязательных свойства. Я создал такой файл, содержащий объект с четырьмя обязательными свойствами, которым, кроме первого (версия стандарта), присвоил пустые значения:
{"version":3,"sources":[],"names":[],"mappings":""}
Браузер принял этот файл, предупреждение исчезло.

Подробнее про карту исходного кода (source map):

https://habr.com/ru/post/509250/
(статья «Source Maps: быстро и понятно» от 02.07.2020)

https://sourcemaps.info/spec.html
(копия стандарта версии 3 от 2011 года)

Сами пять автоматических тестов разобраны в следующем посте.
Tags: Образование, Программирование
Subscribe

  • GIMP, формат PNG, утилита pngcrush

    В одном из предыдущих постов я разбирал постановку задачи в учебнике по JavaScript. Авторы задачи создали тестовую HTML-страницу, на которой…

  • Роскомнадзор и DeviantArt.com, 2021 год

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

  • Название тестового фреймворка Mocha

    Изучая язык JavaScript, узнал о существовании библиотеки «Mocha», предназначенной для создания автоматических тестов для скриптов на языке…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments