Если вы когда-либо писали производственный код, весьма вероятно (или, по крайней мере, рекомендуется), что вы писали тесты. Будь то модульные тесты, интеграционные тесты, визуальные тесты или любой другой тип тестирования, почти каждый разработчик программного обеспечения имеет хотя бы некоторый опыт тестирования. Но тестирование - это более обширная область, чем многие думают - просто посмотрите на количество инструментов тестирования, доступных для Node.js:

(это даже не исчерпывающий список!)

Для большинства языков не существует окончательного инструмента тестирования, но это зависит от нескольких факторов:

  • Какие тесты вы пишете (модульные, интеграционные и т. Д.)
  • Нужны ли вам определенные функции (например, асинхронное выполнение или интеграция с React)
  • Как вы хотите структурировать свои тесты

Greenkeeper работает эффективно только при наличии хороших тестов, поэтому в этом сообщении блога мы поделимся некоторыми из наших рекомендуемых передовых методов при написании тестов!

Тестируйте одновременно с несколькими версиями

Если вы разрабатываете библиотеку, вы хотите убедиться, что она работает с большим количеством версий среды выполнения. Если вы разрабатываете приложение, вы хотите убедиться, что в следующей версии среды выполнения ничего не сломается. Вы можете вручную использовать диспетчер версий для тестирования различных версий, например:

Но это скучно и утомительно! Вместо этого вы можете использовать своего поставщика CI, чтобы сделать это автоматически. Вот пример конфигурации Travis CI:

Настройте матрицу сборки

Если вы хотите пойти еще дальше, чем тестирование нескольких версий, вы можете настроить Матрицу сборки. Это означает, что для каждой версии, которую вы тестируете, вы можете запускать отдельные параллельные задания для выполнения только ваших модульных тестов, ваших интеграционных тестов и т. Д. Проще всего представить это в виде матрицы: для каждой указанной вами версии задания X будут выполняться с разными параметрами, эффективно создавая двухмерную таблицу. Давайте посмотрим, как это настроить в Travis CI:

Это запустит 6 (3x2) заданий, для каждой версии будут запущены тесты с переменной среды TEST_TYPE, установленной на любое значение. Вам решать, как реализовать эти переменные среды, но матрицы построения - мощный инструмент для простого параллельного тестирования нескольких вещей. Если вы все еще запутались, пример использования матрицы сборки можно найти здесь (сборки Travis CI находятся здесь).

Имейте в виду, что Travis CI может одновременно обрабатывать только 4 задания. Кроме того, это бесплатный продукт, поэтому создавайте новые рабочие места только для того, чем вы должны заниматься.

Использовать выход TAP

Вы когда-нибудь начинали работать над существующим проектом и думали: «Я понятия не имею, как интерпретировать результаты этого теста»? Существует так много различных инструментов тестирования, большинство из которых реализуют собственный выходной формат, поэтому иногда бывает сложно сравнивать и переключаться между ними. К счастью, есть спецификация для стандартизированного тестового вывода под названием TAP! Это расшифровывается как Test Anything Protocol, и если вы когда-либо использовали Perl в течение своей жизни, вы, вероятно, использовали его, поскольку он был первоначально разработан в 1987 году для t/TEST core test harness на Perl. Однако в наши дни вокруг него построено множество инструментов для более современных языков.

В JavaScript, например, вы можете использовать ленту для полнофункциональной среды модульного тестирования, которая производит вывод TAP. Эти тесты выглядят примерно так:

Выходные данные TAP для этого выглядят следующим образом:

Красиво и структурировано. Но немного скучно, правда? К счастью для нас, мы можем перекачать наш вывод TAP во что-то вроде сборщика:

Или объедините это со скриптами npm:

Теперь просто запустите npm test и готово! Хороший выход на несколько дней.

Одним из недостатков использования TAP или tape является то, что тесты всегда выполняются последовательно или по порядку. Другие инструменты тестирования, такие как Jest, пытаются запускать тесты параллельно, что делает их принципиально несовместимыми. Тем не менее, некоторые люди пытались преодолеть разрыв, если вы готовы приложить дополнительные усилия.

На сегодня все! Мы могли бы дать еще несколько советов и уловок, если люди будут заинтересованы, но пока: Удачного мая и готовьтесь к JSConf EU! 😎