JSPM был основной частью моего процесса сборки с тех пор, как я начал работать с React. Я впервые влюбился в его автоматическую дедупликацию при выполнении его версии npm install. К сожалению, у него все еще есть проблемы с ростом при выполнении других задач, таких как объединение css, развертывание и, в последнее время, тестирование. Это достижимо, но требуется много работы, чтобы заставить готовую настройку работать.
Большинство фреймворков для тестирования javascript предполагают, что вы будете тестировать библиотеки, установленные с помощью npm. Но в случае с JSPM он заменяет npm. Каталог поиска по умолчанию для модулей npm, опубликованных в npm, — node_modules. Но JSPM делает все по-другому. У меня не было возможности заглянуть внутрь того, как JSPM пытается связать пакеты, но, судя по тому, что я видел, он делает это, создавая промежуточный файл, который связывает JSPM с точкой входа модуля. Таким образом, jspm_packages/npm/[email protected] — это всего лишь одна строка, требующая, например, jspm_packages/npm/[email protected]/mocha.js.
Что это оставляет нас, тогда? Я посмотрел на ленту и ава, но их поддержка исходных файлов ES6 отсутствовала. Тем не менее, ava поддерживает ES6 в тестовых файлах, так что это плюс, но этого недостаточно. Кроме того, я импортирую библиотеки из JSPM в свой код JSPM, поэтому эти библиотеки не смогут их найти (вместо этого они будут искать в node_modules).
Пробуя другой подход, я искал существующие решения для тестирования JSPM. Моей отправной точкой была официальная документация, но поле было довольно безрадостным.
Этот использует System.import для каждого теста, который импортирует асинхронная версия ES6, что видно из источника его единственного тестового файла. Для меня это довольно громоздко, так как мой код уже написан для импорта ES6, и я хочу сделать то же самое для своих тестовых файлов.
Это был еще один тупик. После нескольких часов выяснения конфигураций кармы (особенно выяснения того, когда карма загружала и не загружала мои тестовые файлы с помощью флага — log-level debug и ), мне удалось получить рабочая установка! Но затем я столкнулся с ошибкой, когда попытался запустить ту же установку в Ubuntu (я использую OSX). Похоже, проблема недавно была исправлена, так что попробовать все же стоит. Ниже приведена конфигурация, которую я получил для работы.
Мне пришлось прибегнуть к sed, чтобы на лету изменить baseURL в config.js на пустую строку из-за очередной проблемы совместимости.
В конце концов, я нашел решение, основанное на запуске мокко в браузере на базе PhantomJS. Это решение, на котором я в конце концов остановился, и с тех пор доволен им.
Это решение было не лишено недостатков, так как не было возможности подставить все мои тестовые файлы из коробки. Позже я добавил 2 скрипта, один для повторного изменения baseURL, а другой для группирования всех тестовых файлов. Еще одна проблема, которую я не смог решить, заключалась в том, что вызов для загрузки сгенерированного списка тестовых файлов, каким бы маленьким он ни был, мог занимать до 4 секунд! В результате у меня довольно мягкий тайм-аут, 10 секунд.
И вот оно! Преимущество этой настройки в том, что она также позволяет выполнять отладку в браузере, просто открыв mocha.html.
Еще одна модификация, которую мне пришлось сделать, заключалась в вызове window.initMochaPhantomJS() из-за этой проблемы. Оборачивая его в проверку if, я также гарантирую, что тестовая страница работает и в браузере.
Кроме того, я добавляю мокко и чай к своим глобальным переменным, чтобы иметь легкий доступ к описанию, описанию и ожиданиям. Однако это может зависеть от ваших личных предпочтений.
