В Часть 6 мы говорили о тестах и ​​о том, как мы можем использовать Mocha и Sinon для их написания. Итак, теперь, когда наш код протестирован, все должно быть в порядке, верно? Ну, не совсем, потому что некоторые детали были опущены в Часть 6 для удобства, но они подрывают доверие к нашим тестам. Итак, давайте начнем исправлять это!

Глядя на работу, проделанную в Часть 6, можно заметить, что некоторые вещи упущены:

  • Наши тесты выполняются для кода, полученного в результате компиляции с помощью Babel, но наш рабочий код является результатом объединения с webpack, поэтому мы не тестируем окончательный код.
  • Тесты выполняются в узле, в идеале их следует запускать в реальной среде, в браузере.
  • Поскольку мы запускаем наши тесты в среде node, нам нужно настроить поддельный метод window.alert, чтобы мы не использовали настоящий метод.
  • Покрытие кода отсутствует, что означает, что мы тестируем наш код, но мы не знаем, какая часть кода протестирована/покрыта тестами.

Есть много способов решить эти проблемы, и в нашем случае мы сделаем это с помощью средства запуска тестов Karma, которое поможет нам запустить пакет webpack тестировать код и запускать их в браузере (также стоит отметить, что Karma поддерживается сервисами CI, такими как Travis CI или Семафор). Давайте установим его:

$ npm install karma --save-dev

После установки запустите команду Karma init, чтобы инициализировать файл конфигурации:

$ node_modules/.bin/karma init

Теперь ответьте так:

  • Платформа тестирования: мокко
  • Использовать Require.js: нет
  • Автоматический захват любого браузера: Chrome, Firefox
  • Расположение исходных и тестовых файлов: test/**/*.spec.js
  • Шаблон исключения файлов: (оставьте пустым)
  • Смотреть все файлы: да

ПРИМЕЧАНИЕ. Для работы Karma с этой конфигурацией вам необходимо установить Chrome и Firefox, поэтому либо установите их, либо удалите из конфигурации тот, который вы не используете. Для тех, кто спрашивает, почему бы нам не добавить PhantomJS (который является безголовым браузером и поэтому теоретически быстрее работает), вероятность того, что он уже установлен, меньше, поэтому я не добавил его. Но процесс его работы должен быть таким же, поэтому не стесняйтесь добавлять его, если хотите :)

После ответов на вопросы Karma создаст файл конфигурации с именем karma.conf.js, а также установит пакеты на основе наших ответов и сохранит их как зависимости в package.json (если вы откроете его, в нем должны быть перечислены karma-mocha, karma-chrome-launcher и karma-firefox-launcher как devDependencies). Говоря о package.json, давайте создадим скрипт для запуска Karma:

“scripts”: {
  // ...
  “test:browser”: “node_modules/.bin/karma start”

Мы могли бы попробовать выполнить команду прямо сейчас, но это не сработает, потому что, как вы уже догадались, Karma попытается загрузить файлы, соответствующие шаблону test/* */*.spec.js в браузер, и они еще не включены. К счастью, мы можем использовать karma-webpack, который представляет собой препроцессор (нечто эквивалентное загрузчикам webpack) для создания Karma свяжите наш код перед загрузкой в ​​браузере. Установите его, выполнив:

$ npm install karma-webpack --save-dev

И настройте Karma для его использования, отредактировав karma.conf.js следующим образом:

preprocessors: {
  'test/**/*.spec.js': ['webpack']
},
webpack: require('./webpack.config.js')

Нам также нужно настроить webpack внутри Karma, потому что он не подберет конфигурацию в webpack.config.js сам по себе . Хорошо, что мы можем сами запросить файл и передать его в качестве конфигурации. Теперь давайте попробуем запустить тестовую команду, чтобы посмотреть, что произойдет:

$ npm run test:browser

Karma запустит Chrome и Firefox, запустит тесты и сообщит о результатах:

Karma будет продолжать работать даже после сообщения о результатах, потому что мы настроили его для отслеживания файлов, чтобы, аналогично webpack-dev-server, изменять файлы. автоматически запустит новый тестовый прогон. Чтобы попробовать это, удалите из popup.spec.js условие if, которое устанавливает фальшивое окно, и сохраните его. Это должно инициировать новый тестовый запуск (вернуть popup .spec.js после того, как попробовали это, так как мы по-прежнему хотим, чтобы тесты проходили при запуске с Mocha).

Хорошо, тесты проходят, но подождите! Теперь у нас есть отчеты об ошибках ESLint! Это происходит из-за того, что тестовые файлы также линтингуются, и хотя в этом нет ничего плохого, мы не хотим применять те же правила, что и к другим файлам, потому что стрелочные функции не рекомендуются в Mocha , поэтому мы создадим новую конфигурацию ESLint только для этих файлов. Создайте новый файл конфигурации в каталоге test с именем .eslintrc.json со следующим содержимым:

И благодаря волшебству каскадной конфигурации ESLint это именно то, что нужно! Запустите Karma и убедитесь в этом сами.

Хорошо, теперь все выглядит хорошо… Или нет? К сожалению, у этой настройки есть изъян… При работающем Karma откройте src/popup.js и измените строку 9 на «capitalize» с ошибкой, чтобы test терпит неудачу и сохраняет его:

const output = this.capitalize ? _.capitaliz(text) : text;

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

О, тесты проваливаются, давайте проверим, где они провалились... В строке 155 файла popup.spec.js? Это не имеет смысла, верно? Ну, на самом деле это так, помните, что тесты выполняются с связанным кодом, а не с исходным кодом, так что Карма не знает как сообщить строку, соответствующую исходному коду. Мы можем решить эту проблему с помощью sourcemaps. Сначала мы устанавливаем загрузчик, необходимый Karma для поддержки soucemaps:

$ npm install karma-sourcemap-loader --save-dev

Откройте karma.conf.js и добавьте его в качестве препроцессора:

preprocessors: {
  'test/**/*.spec.js': ['webpack', 'sourcemap']
}

Наконец, нам нужно сгенерировать sourcemaps, и это можно сделать в webpack, поэтому откройте webpack.config.js и добавьте следующее линия:

devtool: 'inline-source-map'

Перезапустите Karma, чтобы загрузить новую конфигурацию, и вы должны увидеть следующее:

Теперь он идентифицирует строку с ошибкой в ​​исходном коде, удивительно, правда?! В этой конфигурации нужно учитывать только одну вещь: теперь связанные файлы всегда будут генерироваться с исходными картами, чего мы не хотим при отправке код в производство. Есть много способов добиться этого, и я хочу решить проблему с помощью переменных среды довольно простым способом, поэтому давайте откроем webpack.config.js и отредактируем его следующим образом:

const path = require(‘path’);
const PRODUCTION = process.env.NODE_ENV === 'production';
module.exports = {
  // ...
  devtool: PRODUCTION ? '' : 'inline-source-map'
};

В node мы можем получить переменную окружения через объект process.env, а оттуда все остальное тривиально.

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

Код выложен здесь.

Спасибо за чтение!

PS: Часть 8 здесь.