Mocha мне ближе, чем любой другой тестовый фреймворк, с которым мне приходилось работать. Я люблю читать и писать идиоматический код. Самое лучшее во всех причудливых библиотеках — это то, что они помогают нам писать идиоматический код.
Они затягивают нас в свой мир. Они дают какие-то примитивные структуры и дают нам инструменты. Они помогают вам думать по-другому (правильно), что делает написание кода более простым и интуитивно понятным.
Рабочий процесс КИ
Многие компании и проекты используют непрерывную интеграцию (часто упоминаемую как CI). Эти системы CI позволяют запускать тесты, генерировать отчеты о покрытии и т. д. всякий раз, когда какой-либо код объединяется в проекте.
Эти тесты выполняются на другом компьютере и обычно предоставляются системой SaaS CI. Когда тесты терпят неудачу или охват ниже ожидаемого, эти системы CI уведомляют об этом через свои веб-панели, приложения для обмена сообщениями, такие как Slack, Gitter и т. д.
Проблемы с гитхабом
Трекер задач Github — отличный инструмент для работы над программными проектами. Это помогает в отчетности, отслеживании и сортировке ошибок, запросах функций и т. д.
Наиболее часто встречающийся рабочий процесс выглядит так. Когда один человек объединяет некоторый код в главную ветку (последнюю ветку), система CI срабатывает и сообщает об ошибке на веб-панели. Мейнтейнер проекта или кто-то другой наблюдает за этим, открывает задачу в github и помечает ее соответствующей меткой. Человек, который сломал сборку, или кто-то еще сливает исправление, пока сборка не станет зеленой и окончательно не закроет проблему github.
Люди обычно (по крайней мере, я) часто заходят на веб-панель систем CI только тогда, когда сборка завершается с ошибкой, и копируют данные о неудачном тесте в github issue.
Автоматизация создания задач на Github
Я видел код, который сообщает о результатах тестов внутри самих тестов мокко.
// WARNING: Following code snippet is a bad practice. describe('test suite', function () { // store failed tests for reporting var failedTests = []; it('test case 1', function () { // some test }); it('test case 1', function () { // some test }); after(function () { if (failedTests.length > 0) { // make HTTP call to create github issue } }); });
Как вы можете догадаться, эта функция after
копируется во все файлы тестовых примеров и приводит к дублированию кода повсюду.
Прочитав где-то такой код, я начал задавать себе несколько основных вопросов.
1.Что можно сделать, чтобы избежать такого дублирования?
2. Какая правильная абстракция отделяет тесты от того, как о них сообщают?
Просматривая мокко-документы, я случайно обнаружил мокко-репортеров.
Мокко Репортеры
После завершения тестов мокко-репортеры представляют собой интерфейсы, которые визуально сообщают результаты тестов разработчику. Они варьируются от вывода причудливого форматированного текста до вывода в формате html.
Так вот, об этом я и говорил в самом начале. Reporters — это просто абстракция, предоставляемая mocha для представления ваших тестовых данных.
Я решил быстро выкатить библиотеку, которую можно использовать как devDependency в проекте.
Познакомьтесь с mocha-github-репортером
Это настраиваемый репортер mocha, который можно использовать для отчета о результатах теста mocha как о проблеме github из различных систем CI.
Он опубликован в npm, а его исходный код доступен в открытом виде на github.
Установить
Его можно установить как devDependency через npm.
$ npm install --save-dev mocha-github-reporter
использование
Настройка должна быть простой. Сначала необходимо установить необходимые переменные среды.
- GITHUB_ACCESS_TOKEN — можно сгенерировать здесь. Убедитесь, что вы не раскрываете этот токен и используете его как переменную безопасной среды в вашей системе CI.
- GITHUB_REPO_SLUG — репозиторий Github, в котором нужно создать задачу для результатов тестирования.
- REPORT_TITLE — Название создаваемой задачи. Он может использовать переменные среды, специфичные для CI, чтобы быть более актуальными. Например: отчет Mocha для сборки $BUILD_NUMBER.
- REPORT_ALWAYS — по умолчанию проблема Github создается только в случае сбоя тестов. Установка для этой переменной значения
true
создаст проблему Github, даже если все тесты пройдены. - REPORT_FORMATTER — доступны различные встроенные средства форматирования. Мы увидим их одного за другим внизу.
После того, как необходимые переменные среды установлены, нам просто нужно запустить mocha.
$ mocha --reporter mocha-github-reporter tests/
Форматтеры
Следующие средства форматирования используются переменной окружения settingREPORT_FORMATTER
.
все люксы
Это средство форматирования по умолчанию, похожее на стандартный репортер мокко.
все наборы-эмодзи
Где веселье, если у нас нет репортера-смайлика?
emoji можно настроить с помощью переменных окружения PASSED_EMOJI
и FAILED_EMOJI
.
неудачный контрольный список
Это очень самоуверенный формат. Я видел рабочие процессы, в которых люди создают контрольный список для неудачных тестов и удаляют их один за другим.
Вот и все. Мы отделили код для отчетов о результатах тестов от реальных тестов.
Спасибо, что нашли время, чтобы прочитать это. Пожалуйста, поделитесь своими предложениями и мыслями по этому поводу.