Где проходят тесты

Автоматизированные тесты обычно можно запускать путем запуска сценария вручную или с помощью помощника из среды тестирования, часто называемого средством запуска тестов , для поиска и запуска тестов. Однако вам не всегда может потребоваться запускать сценарии вручную. Существует несколько способов запуска тестов, которые могут обеспечить обратную связь и уверенность на разных этапах жизненного цикла разработки.

Предварительный сценарий

Веб-проекты обычно имеют файл конфигурации — файл package.json — который настраивается с помощью npm, pnpm, Bun или аналогичных программ. Этот файл конфигурации содержит зависимости вашего проекта и другую информацию, а также вспомогательные сценарии. Эти вспомогательные сценарии могут включать в себя инструкции по созданию, запуску или тестированию вашего проекта.

Внутри package.json вам нужно будет добавить скрипт под названием test , который описывает, как запускать ваши тесты. Это важно, поскольку при использовании npm или аналогичного инструмента «тестовый» скрипт имеет особое значение . Этот сценарий может просто указывать на один файл, который выдает исключение (что-то вроде node tests.js ), но мы рекомендуем использовать его для указания на установленный инструмент запуска тестов.

Если вы используете Vitest в качестве средства запуска тестов, ваш файл package.json будет выглядеть следующим образом:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

При запуске npm test с этим файлом один раз запускается набор тестов Vitest по умолчанию. В Vitest по умолчанию нужно найти все файлы, заканчивающиеся на «.test.js» или подобные , и запустить их. В зависимости от выбранного вами средства запуска тестов команда может немного отличаться.

В качестве примеров в этом курсе мы решили использовать Vitest, все более популярную среду тестирования. Подробнее об этом решении можно прочитать в Vitest как тестировщике . Однако важно помнить, что среды тестирования и средства выполнения (даже на разных языках) обычно имеют общий язык.

Ручной тестовый вызов

Запуск автоматических тестов вручную (например, использование npm test в предыдущем примере) может оказаться практичным, пока вы активно работаете над базой кода. Написание тестов для функции во время ее разработки может помочь вам понять, как эта функция должна работать — это затрагивает концепцию разработки через тестирование (TDD).

У средств запуска тестов обычно есть короткая команда, которую вы можете вызвать для запуска некоторых или всех ваших тестов, и, возможно, режим наблюдателя, который повторно запускает тесты по мере их сохранения. Все это полезные параметры при разработке новой функции, и они созданы для того, чтобы упростить написание новой функции, ее тестов или того и другого, и все это с быстрой обратной связью. Например, Vitest по умолчанию работает в режиме наблюдателя: команда vitest будет отслеживать изменения и повторно запускать любые найденные тесты. Мы рекомендуем оставлять это окно открытым в другом окне, пока вы пишете тесты, чтобы вы могли быстро получать отзывы о тестах по мере их разработки.

Некоторые программы запуска также позволяют помечать тесты как only в вашем коде. Если ваш код включает only тесты, то при запуске тестирования будут запускаться только эти тесты, что ускоряет разработку тестов и упрощает устранение неполадок. Даже если все ваши тесты выполняются быстро, использование only может снизить накладные расходы и устранить отвлекающие факторы от выполнения тестов, не связанных с функцией или тестом, над которым вы работаете.

Для небольших проектов, особенно проектов с одним разработчиком, вы также можете выработать привычку регулярно запускать весь набор тестов вашей кодовой базы. Это особенно полезно, если ваши тесты небольшие и выполняются быстро (не более чем за несколько секунд для всех ваших тестов), чтобы вы могли убедиться, что все работает, прежде чем двигаться дальше.

Запускайте тесты в рамках предварительной отправки или проверки.

Многие проекты предпочитают подтверждать правильность функционирования кодовой базы, когда код необходимо объединить обратно в его main ветку. Если вы новичок в тестировании, но в прошлом участвовали в проектах с открытым исходным кодом, вы, вероятно, заметили, что часть процесса запроса на включение (PR) подтверждает, что все тесты проекта пройдены, а это означает, что ваш новый интересный вклад еще не прошел. негативно повлияло на существующий проект.

Если вы запускаете тесты локально, онлайн-репозиторий вашего проекта (например, GitHub или другая служба размещения кода) не будет знать, что ваши тесты проходят успешно, поэтому запуск тестов в качестве задачи предварительной отправки дает понять всем участникам, что все работает.

GitHub, например, называет их «проверками статуса», которые вы можете добавить с помощью GitHub Actions . Действия GitHub — это, по сути, своего рода тест: каждый шаг должен быть успешным (не провалиться или не вызвать Error ), чтобы действие прошло успешно. Вы можете применить действия ко всем запросам на участие в проекте, и проект может потребовать, чтобы действия прошли, прежде чем вы внесете код. Действие Node.js в GitHub по умолчанию запускает npm test в качестве одного из шагов.

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

Запуск тестов в рамках непрерывной интеграции

Как только ваш зеленый PR будет принят, большинство кодовых баз снова запускают тесты на основе main ветки вашего проекта, а не предыдущего PR. Это может происходить немедленно или на регулярной основе (например, каждый час или ночь). Эти результаты часто отображаются как часть панели мониторинга непрерывной интеграции (CI), которая показывает общее состояние проекта.

Этот шаг CI может показаться излишним, особенно для проектов с небольшой базой кода — тесты проходят во время проверки, поэтому они должны пройти после внесения изменений. Однако это не всегда так! Ваши тесты могут внезапно завершиться неудачно, даже после успешного получения «зеленых» результатов. Некоторые причины этого включают в себя:

• Несколько изменений были приняты «сразу», что иногда называют состоянием гонки, и они влияют друг на друга тонкими, непроверенными способами.
• Ваши тесты невоспроизводимы или они проверяют «ненадежный» код — они могут как пройти, так и провалиться без изменений кода.
  • Это может произойти, если вы зависите от систем, внешних по отношению к вашей кодовой базе. Для прокси-сервера представьте, что вы тестируете Math.random() > 0.05 — в 5% случаев это может привести к случайному сбою.
• Некоторые тесты слишком затратны или дороги для запуска при каждом PR, например сквозные тесты (подробнее об этом см. типы автоматизированного тестирования ), и они могут со временем выйти из строя, не всегда вызывая оповещения.

Ни одну из этих проблем невозможно решить, но стоит понимать, что тестирование и разработка программного обеспечения в целом никогда не станут точной наукой.

Интерлюдия на откате назад

Когда тесты запускаются как часть непрерывной интеграции и даже когда тесты запускаются как часть проверки состояния, возможно, что сборка окажется в «красном» состоянии или в другом состоянии, означающем, что тесты не пройдены. Как упоминалось ранее, это может произойти по ряду причин, включая условия гонки при отправке теста или нестабильные тесты.

В случае с небольшими проектами вы можете инстинктивно отнестись к этому как к кризису! Остановите все, откатите или отмените некорректное изменение и вернитесь в заведомо хорошее состояние. Это может быть правильным подходом, но важно помнить, что тестирование (и ПО в целом!) — это средство для достижения цели , а не самоцель. Ваша цель, вероятно, — написать программное обеспечение, а не пройти все тесты. Вместо этого вы можете выполнить накат, дополнив критическое изменение другим изменением, исправляющим неудачные тесты.

С другой стороны, вы, возможно, видели или работали над крупными проектами, которые постоянно находятся в нерабочем состоянии. Или, что еще хуже, у большого проекта есть ненадежный тест, который ломается достаточно часто, что вызывает усталость разработчиков. Зачастую это экзистенциальная проблема, которую приходится решать лидерам: эти тесты могут даже отключить, потому что они считаются «мешающими на пути развития».

Быстрого решения этой проблемы не существует, но это может помочь стать более уверенным в написании тестов (повышение квалификации) и сократить объем тестов (упрощение), чтобы можно было легче выявлять сбои. Увеличение количества компонентных или интеграционных тестов (подробнее о типах см. в разделе «Типы автоматизированного тестирования» ) может обеспечить большую уверенность, чем один огромный сквозной тест , который сложно поддерживать и который пытается сделать все сразу.

Ресурсы

• Каковы преимущества ночных сборок

Проверьте свое понимание