Полезные команды Playwright

«Инициализируйте новый проект 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, чтобы запускать только один тест за раз. Я считаю эту комбинацию очень удобной, когда концентрируюсь на сложном и нестабильном тест-кейсе.»

Stefan Judis


Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас

casibom 780casibom giriş güncel adrescasibom 760 girişJojobetjojobetCasibom Girişdeneme bonusuJojobet Girişcasibom girişcasibomJojobet GirişCasibomCasibomcasibomcasibom girişcasibom güncel girişHoliganbet Giriş