Одним из столпов платформы Bonzai является SharePoint Framework. Эта платформа объединяет различные API SharePoint (SOAP, REST и JSOM), чтобы наши разработчики могли сосредоточиться на своих решениях, а не на таких вещах, как чтение профилей пользователей. В дополнение к проблемам, связанным с включением различных API-интерфейсов SharePoint в единую структуру, мы обнаружили, что модульное тестирование этого кода очень сложно. Поэтому передо мной стояла задача найти решение. Вот!
Я решил использовать средство запуска тестов Mocha, потому что Bonzai Framework использует нативные промисы для возврата всех запросов. Chai As Promised добавил очень приятный и читаемый язык утверждений.
Bonzai Framework написан на ES6, и я хотел написать тесты на ES6. Для этого мне просто нужно было добавить Babel Polyfill.
Я использовал следующую команду, чтобы позволить mocha использовать babel для компиляции тестов:
mocha tests/fieldCollection_spec.js — compilers js:babel-core/register
И получил этот прекрасный результат:
Первый тест проходит, как и ожидалось. Bonzai Framework отклонит любой запрос FieldCollection.all() без имени списка. Но когда дело доходит до фактического запроса, мы получаем «SP не определен». Будет ли полезно, если я сейчас упомяну, что Bonzai Framework предназначена для использования в качестве оболочки для API Sharepoint JSON и REST?
SP — это глобальный объект, необходимый для выполнения всех запросов API JSON.
Так что теперь мне пришлось все переосмыслить. Мы не можем запускать тесты в Node, потому что нам нужен доступ к глобальному объекту SP Sharepoint, а также другие вещи Sharepoint, такие как аутентификация. Я решил скомпилировать тесты и сценарии в один большой файл, загрузить их на страницу Sharepoint, а затем запустить тесты. Поскольку Framework работает только в среде Sharepoint, логично, что он также требуется для тестов.
Я попытался включить Mocha непосредственно в свой тестовый код следующим образом:
Это сработало, когда я запустил ту же команду mocha, что и выше, но потерпел неудачу, когда попытался скомпилировать файл в удобный для браузера код. Очевидно, Mocha плохо работает с Browserify/Babelify, есть текущая ветка, если кто-то хочет помочь с этим. https://github.com/mochajs/mocha/issues/1316
К счастью, существует отдельная версия mocha, которая уже включена в версию mocha для узла. Собрав файлы спецификаций так, как я хочу, а затем запросив их оба на странице, все работает хорошо.
Код, который я добавил в Sharepoint, в веб-части редактора сценариев выглядит следующим образом:
И окончательные результаты испытаний:
Если файлы вообще не загружаются, проверьте консоль на наличие этой ошибки:
Если вы видите это, Chrome не загружает файлы, потому что они не используют настоящий SSL. Если вы откроете URL-адрес в новом окне, вы получите предупреждение, которое выглядит следующим образом:
Если вы нажмете ссылку «Перейти к локальному хосту (небезопасно)», Chrome добавит исключение для домена. Теперь, если вы вернетесь на тестовую страницу, она загрузится. Это нужно делать каждые несколько дней.
Теперь, когда у меня было тестирование, я начал задумываться о покрытии кода. Тесты — это здорово, но тесты и покрытие кода — супер. Похоже, что большинство современных библиотек покрытия кода были созданы для работы в узле и не могли работать в браузере. К счастью, мы наткнулись на BlanketJS, у которого есть отдельная версия для браузера.
Короче говоря (и пару дней ругани) мы получили вот такую конфигурацию:
Вот краткий обзор изменений, которые нам пришлось внести, чтобы Blanket заработал:
- Не включайте модули Framework в файлы спецификаций, используйте глобальный объект BZ framework.
- Загрузите скомпилированный файл Framework непосредственно в Sharepoint и отметьте его как цель покрытия.
- Подавать файлы через http, а не https
- Добавьте исключение в Chrome для обслуживания небезопасных скриптов
Файлы, которые в итоге заставили его работать, взяты из этого примера: https://nicolas.perriault.net/code/2013/get-your-frontend-javascript-code-covered/
Предупреждение: при загрузке модуля XHR произошла ошибка, переопределяющая переменную окна. В целях тестирования мы должны удалить строку кода, которая переопределяет переменную окна. В долгосрочной перспективе нам придется найти модуль xhr, который этого не делает.
Когда все на своих местах, мы наконец можем увидеть покрытие кода, отображаемое на странице:
К сожалению, поскольку мы рассматриваем скомпилированный файл, там много стандартного кода, и все модули узлов также находятся там. Но мы видим, что наш код тестируется:
Немного тяжело читать, но все же полезно.
В конце концов, мне удалось провести тестирование на странице Sharepoint, сохранив при этом современные элементы Node.js и ES6, которые я хотел использовать.
Мы очень рады выпуску нашей Bonzai Framework в качестве проекта с открытым исходным кодом. Мы считаем, что это добавляет уровень ясности, что приводит к более чистому коду и экономит время в процессе разработки.