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.

неудачный контрольный список

Это очень самоуверенный формат. Я видел рабочие процессы, в которых люди создают контрольный список для неудачных тестов и удаляют их один за другим.

Вот и все. Мы отделили код для отчетов о результатах тестов от реальных тестов.

Спасибо, что нашли время, чтобы прочитать это. Пожалуйста, поделитесь своими предложениями и мыслями по этому поводу.

Быстрые ссылки