Англійською мовою: Playwright Testing

Playwright швидко став інструментом для тестування браузера end-to-end, і робота з ним означає вивчення певного набору англійських термінів. Неважливо, пишете ви тести, переглядаєте запит на збирання, надісланий колегою, або повідомляєте про оновлення специфікації, знання правильного словника зробить ваше спілкування точним і професійним. У цьому підручнику розглянуто ключові терміни і найприродніші способи їх використання у справжніх робочих розмовах.

Ключовий словник

Локатор Об’ єкт, специфічний для Playwright, який знаходить один або декілька елементів на сторінці і взаємодіє з ними. Локатори є лінивим — вони розв’ язують проблеми лише тоді, коли ви виконуєте дію з ними. Приклад: «Я переключився з page.$() на локатор, тому що локатори мають вбудоване автоматичне очікування.»

• Зачекай Частина налаштування тестів, яку можна використовувати повторно, надається для тестів за допомогою введення залежностей. Вбудовані фітинги Playwright включають page, browser, і context ; команди також пишуть нетипові фітинги для спільного стану входу або API-клієнтів.

• Приклад: « Я витягнув автентифікований сеанс у інструмент, щоб не повторювати поток входу у кожному тесті. » *

** Утверждение ** Інструкція, яка перевіряє, чи знаходиться програма у очікуваному стані. Playwright використовує expect() з веб-першими збігами, які автоматично повторюють спроби доти, поки умова не буде виконана або не буде досягнуто тайм-аута.

• Приклад: « Указівка чекає до п’ яти секунд на те, щоб елемент став видимим, перш ніж вона зазнає невдачі. » *

** Модель об’ єкта сторінки (POM) ** Шаблон проектування, який обгортає взаємодії сторінок у спеціальний клас, відокремлюючи логіку тестування від деталей селекторів. Зміни у інтерфейсі користувача вимагають лише оновлення об’ єкта сторінки, а не кожного окремого тесту. Приклад: “Ми маємо клас LoginPage в нашому POM — оновити селектор там і всі тести підберуть його.”

** Перехоплення мережі ** Можливість перехоплювати, перевіряти, змінювати або імітувати HTTP- запити і відповіді під час тестування. У Playwright це робиться з page.route().

• Приклад: « Я використовував перехоплення мережі для блокування API платежу, щоб тест не збирав гроші з реальної карти. »*

• Трах Детальний запис тестового запуску, який містить хронологічну шкалу, знімок вікна кожної дії, мережеві запити і журнали консолі. Шляхи є безцінними для зневадження помилок у CI.

• Приклад: « Тест був зеленим локально, але червоним у CI — я відкрив трасування і побачив, що модальний відтворював з затримкою 200 мс. »*

** Паралельне виконання ** Запуск декількох тестів або тестових файлів одночасно у окремих робочих процесах переглядача, щоб скоротити загальний час роботи тестового пакета.

• Приклад: “Ми скоротили конвеєр з 12 хвилин до 4, ввівши паралельне виконання на чотирьох робочих.” *

Тест на блиск Тест, який проходить і провалюється непослідовно без будь- яких змін у тестованому коді. Флакіність зазвичай спричиняють проблеми з часом, спільний стан або відмінності середовища. Приклад: “Ця специфікація була неточною весь тиждень — додамо правильну заяву замість того, щоб покладатися на твердо кодоване очікування.”

Звичайні фрази

** В обзорах коду: **

• “Цей локалізатор занадто широкий — він буде відповідати декільком елементам, якщо сторінка зміниться. Чи можемо ми використовувати getByRole або getByTestId замість цього?»
• «Я б пересунув цю настройку в пристрій, щоб вона могла використовуватися в цілому готелі»
• «Утвердження тут повинно використовувати toBeVisible(), а не перевіряти DOM безпосередньо — це дає вам автоматичну повторну спробу безкоштовно»

В стоячих позах:

• «Я розслідую тест на тріщини в потоці оплати — слід показує умову гонки на кнопці оплати»
• «Всі тести end-to-end проходять; Я зараз вмикаю паралельне виконання, щоб конвеєр був менш ніж за п’ять хвилин»
• «Я додав перехоплення мережі для сторонньої кінцевої точки аналітики, тому наші тести не залежать від зовнішньої служби»

** У документації: **

• «Кожен тест отримує page пристрій, що вказує на свіжий контекст браузера — немає витоку стану між тестами.»
• «Траси завантажуються як артефакти CI при невдачі; відкрийте .zip в Playwright Trace Viewer, щоб відтворити тест крок за кроком»
• Нестандартні фітинги визначені в fixtures/index.ts і розширені з @playwright/test

Фрази, яких слід уникати

** Як сказати « тест очікує на елемент » ** — точнішим варіантом буде « локалізатор повторює спроби до тих пір, поки елемент не буде видимим » або « твердження повторює спроби до тих пір, поки не буде виконано умову ». Playwright не використовує пасивне очікування; у ньому використовуються розумні повтори.

** Використання слова « mock », коли ви маєте на увазі « перехоплення » ** — перехоплення замінює всю залежність; перехоплення дозволяє провести справжній запит, але може його змінити. Скажіть “Я перехопив запит і змінив відповідь”, а не “Я насміхався над запитом”

** Як сказати « the test broke » ** — у англійській мові, тести * не спрацьовують *, а не спрацьовують. « The test failed in CI » — це правильна фраза. « Broke » звучить неформально і не так точно. Залишити « broken » для випадків, коли зміна коду призвела до аварії самої програми: « the refactor broke the login flow. »

Краткий справочник

Term	How to use it
locator	”Use a role-based locator to keep tests resilient to CSS changes.”
fixture	”Our auth fixture handles login once and shares the cookie across all tests in the file.”
assertion	”The assertion timed out — the element never reached the expected state.”
trace	”Grab the trace from the CI artifact and open it in Trace Viewer.”
flaky test	”We tagged it as flaky and opened a ticket to investigate the root cause.”

Навигація зворотного зв’язку — практичний підхід до не-національної англійської

Найбільша перешкода для багатьох нових до технічної області - це не * що *, а * як * - конкретно, як сформулювати проблеми, запропонувати рішення і отримати ефективний зворотній зв’язок. Погляньмо правді в очі, професійна англійська мова в розробці програмного забезпечення часто нюансована, сильно покладаючись на точну термінологію і конкретні фрази. Для не-рідних носіїв, це може відчувати себе неймовірно пригнічуючим, особливо коли стикаються з переглядом коду або складними дискусіями про стратегію тестування. Не достатньо просто розуміти поняття; вам потрібно бути в змозі виразити їх чітко і впевнено.

Однією з поширених областей труднощів є оформлення зворотного зв’язку - чи давати його, чи отримувати його. Типовий сценарій включає в себе коментар перегляду коду на PR, можливо, щодо надто складного локатору. Замість того, щоб сказати: «Цей селектор занадто довгий», що звучить незграбно і, можливо, зневажливо, більш професійним підходом буде: «Я помітив, що XPath для цього елемента досить довгий. Чи можемо ми дослідити альтернативні локатори - можливо, використовуючи CSS- селектор або використовуючи селектор атрибутів - щоб поліпшити підтримку і зменшити потенційну крихкість, якщо основний HTML змінюється? Це демонструє розуміння ширших наслідків (підтримка, крихкість) за межами просто негайної проблеми. Аналогічно, коли ви отримуєте критику, відповідайте: «Гаразд, я розумію, що ви маєте на увазі про вплив на продуктивність. Дозвольте мені дослідити, використовуючи більш прицільний локатор. ” є набагато більш продуктивним, ніж оборонний “але це працює!”

Інша часта проблема виникає в описах PR. Хороший опис PR повинен чітко описувати * чому * тест був написаний і що він має на меті досягти. Недостатньо простого твердження на зразок « Перевірка реєстрації »; замість цього спробуйте вказати: « Цей тест Playwright перевіряє успішний реєстраційний процес користувача з коректними даними реєстрації, включаючи обробку стандартних повідомлень про помилки ». Цей рівень деталізації є ключовим для переглядачів, щоб вони могли швидко зрозуміти мету і обсяг тесту. Також важливо бути проактивним у документуванні припущень — наприклад, «Припускає стандартне ім’я користувача та пароль англійською мовою»

Нарешті, пам’ ятайте, що запитання прояснюючих питань * завжди * краще, ніж припущення. Якщо ви не розумієте коментар або вимогу, ввічливо запитайте про пояснення: « Чи могли б ви розібратися, що ви маєте на увазі під « випадками покриття краю » у цьому сценарії? » Показ готовності до навчання і пошуку розуміння демонструє професіоналізм і зменшує ймовірність неправильного тлумачення.

Ось приклад, який показує, як використовувати Playwright для повідомлення про проблему, знайдену під час тестування:

import playwright
from playwright.sync_api import sync_playwright

def run_test():
    with sync_playwright() as pw:
        browser = pw.chromium.launch(headless=False)  # Keep browser open for inspection
        page = browser.new_page()
        page.goto("https://example.com/login") # Replace with your test URL

        # Simulate login attempt (replace with actual input)
        page.fill("#username", "testuser")
        page.fill("#password", "password123")
        page.click("#submit-button")

        # Assert that the user is logged in successfully
        assert page.locator("#login-success-message").text() == "Welcome, testuser!" # Replace with your assertion

        browser.close()

if __name__ == "__main__":
    run_test()

Цей простий приклад показує, наскільки важливою є чітка і точна мова під час документування * причини * для тестування — у цьому випадку, перевірки успішного входу за допомогою певних елементів, визначених на сторінці. Пам’ ятайте, ефективне спілкування зменшує тертя, покращує співпрацю і, врешті-решт, призводить до вищої якості програмного забезпечення.