В Часть 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 здесь.