- —last-failed: запуск только упавших
- —only-changed: запуск только измененных файлов
- —repeat-each: контроль стабильности
- —forbid-only: запуск всех тестов всегда
- —headed —workers 1 в обычном режиме
«Инициализируйте новый проект Playwright, установите все зависимости, и для запуска любого нового теста в headless-режиме достаточно одной команды npx playwright test
. Но знаете ли вы все опции? В этом посте я расскажу вам о любимых трюках.
—last-failed
Знакомая ситуация: вы запускаете тестовый набор и видите несколько упавших тест-кейсов. Вы вносите изменения в код приложения или тестовый код и хотите еще раз запустить упавшие тесты.
Можно использовать имя файла спецификации при запуске тестов (npx playwright test failed-test.spec.ts
) или просто на test.only
, но, к счастью, в Playwright есть функция отдельного запуска упавших тестов — флаг CLI --last-failed
.
# Only run the tests that failed in the previous test run $ npx playwright test --last-failed
Playwright записывает скрытый JSON-файл в папку test-results
каждый раз, когда завершает прогон теста. В этом файле хранится информация о результатах тестирования и неудачных тест-кейсах.
{ "status": "failed", "failedTests": [ "ecb7ac7b365afffe0dcb-0992cf0d9df8b5e74dc4" ] }
Полагаясь на --last-failed
, вы можете сосредоточиться на плохих тестах и повторно запустить их, не указывая их вручную.
А что, если вы хотите запускать не падавшие тесты, а только те, которые вы изменяли?
—only-changed
Стандартная практика разработки заключается в использовании Git-веток. Чтобы выпустить новую фичу, вы «разветвляетесь», корректируете код приложения и тестов и затем сливаете все обратно в main-ветку.
Во время разработки вам понадобится запускать только измененные (и новые) тесты — вот тогда-то и пригодится параметр --only-changed
.
# During feature development and test creation: # Files aren't committed yet, and the development of tests is still a work in progress $ git status On branch new-feature Changes not staged for commit: modified: tests/new-feature.spec.ts # Only run the spec files that are uncommitted compared to the current branch $ npx playwright test --only-changed
Команда npx playwright test --only-changed
будет запускать только те тесты, которые не были отправлены коммитом в систему контроля версий. Только модифицированные и новые файлы.
Запуск и тестирование только измененных файлов — хорошее решение, если ваш поток разработки основан на контроле версий, ветвях фич и пулл-реквестах. Пишется новая фича, и запускаются только измененные тесты.
Да, Playwright дружит с Git, возможно у вас возник вопрос, есть ли способ запускать только код, измененный в разных ветках — да, есть.
Playwright запустит все неотправленные коммитом изменения, если вы добавите флаг --only-changed
без дополнительных параметров. Но если флаг с указанием ветки, например main
, Playwright проверит и запустит файлы, которые отличаются в ветках:
# After feature development and ready for pull request: # New test files are committed and ready to merge $ git status On branch new-feature nothing to commit, working tree clean # Run all the spec files that are new or modified compared to the `main` branch $ npx playwright test --only-changed=main
Опция позволяет контролировать хаотичный грязный код и изменения в ветках.
—repeat-each
Прежде чем добавлять тесты в кодовую базу, вы должны убедиться в их стабильности. Вы же не хотите, чтобы именно вы оказались источником проблем? К сожалению, проблема с флейки-тестами заключается в том, что их довольно трудно обнаружить. Как обнаружить и исправить тест, упавший только один раз из ста? Простой и очевидный ответ: прогнать тесты более ста раз.
И обращаемся к встроенной функциональности Playwright. Чтобы запустить один и тот же тест несколько раз, используем --repeat-each
.
# Run all tests 100 times npx playwright test --repeat-each 100 # Run all spec files matching `new-feature` 100 times npx playwright test new-feature --repeat-each 100 # Run all uncommited spec files 100 times npx playwright test --only-changed --repeat-each 100
Если вы прогоните новые тест-кейсы сотню раз, и все сто раз ни один не упал, можете быть уверены, что они стабильные.
—forbid-only
Я уже упоминал об этом: если вы хотите запускать только измененные тест-кейсы, запускайте их параметром test.only
. Я часто использую эту опцию, когда хочу погрузиться в проблемный тест-кейс.
// Only run this test when using `npx playwright test` test.only('Your test', async ({ page }) => { // Your test code... });
Но пометка тестов как only может быть очень рискованным делом. Представьте, что вы случайно слили test.only
в main
-ветку. Тогда сотни тестов могут быть проигнорированы и запустится только ваш «самый приоритетный». И пройдет немало времени, прежде чем вы заметите, что ваш конвейер тестирует не то что должен, потому что никто не обратил внимание на неработающий конвейер тестирования.
Чтобы этого не произошло, поручите Playwright предупреждать вас, если ваши тест-кейсы помечены test.only
.
# Fail the test suite if it includes a `test.only` $ npx playwright test --forbid-only Error: item focused with '.only' is not allowed due to the '--forbid-only' CLI flag: "your-test.spec.ts your test
Во время разработки флаг --forbid-only
не важен, но если вы причастны к конфигурации и настройке CI/CD, я рекомендую включить его.
Сочетание UI-режима с командой —headed —workers 1
Все предыдущие примеры были посвящены запуску сквозных тестов из командной строки. Но вы можете предпочесть разработку тестов в обычном, то есть UI-режиме, потому что он предоставляет больше отладочной информации и позволяет включить режим наблюдения. Режим UI в Playwright просто замечательный!
Я постоянно переключаюсь между запуском тестов из CLI и режимом UI. Режим UI — мой любимый инструмент, особенно когда мне нужно отладить сложный тест-кейс. Однако я не использую «ванильный» режим UI и обычно добавляю дополнительные настройки, чтобы ускорить отладку.
# Run Playwright UI mode but also open browsers # and limit the execution to one test at a time $ npx playwright test --ui --headed --workers 1
Применяя флаг --headed
, я могу полагаться на дополнительную информацию режима UI (логи, сеть и т. д.) и следить за всеми действиями теста в браузере. Чтобы избежать нагромождения окон браузера, я применяю --workers 1
, чтобы запускать только один тест за раз. Я считаю эту комбинацию очень удобной, когда концентрируюсь на сложном и нестабильном тест-кейсе.»