Które przeglądarki naprawdę odpalać

Ten wpis jest częścią serii Podstawy Playwright. Jeśli pominąłeś poprzedni, przeczytaj Część 11 — Sterowanie siecią w Playwright.

Wprowadzenie — trzy przeglądarki, trzy rachunki

Playwright umie puścić Chromium, Firefox i WebKit w jednym configu. Ta linia w configu nie jest decyzją. Decyzją jest, który projekt blokuje merge i który istnieje, bo użytkownik na Safari trafił na błąd niewidoczny w Chrome.

Chromium blokuje pull request

Większość użytkowników i całe debugowanie będzie w Chromium. Kubełek pull requestu z serii CI idzie tutaj. Trace, zrzuty i inspektor zgadzają się z przeglądarką, którą masz otwartą.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] }, grep: /@firefox/ },
    { name: 'webkit', use: { ...devices['Desktop Safari'] }, grep: /@webkit/ },
  ],
});

grep jest tu istotą. Firefox i WebKit nie dziedziczą całej suite.

Kiedy inny silnik zasługuje na tag

Dodaj @webkit, gdy masz błąd albo kontrolkę, którą Safari obsługuje inaczej i której twoi użytkownicy naprawdę używają:

input daty i pliku
position: sticky w kontenerze, od którego zależysz
prośba o uprawnienie, o której jest część 13
widget płatności albo logowania, który ma osobny build pod Safari

@firefox dodawaj z tego samego powodu, nie dla symetrii. Jeśli nie masz defektów z Firefoxa i nie masz tam ruchu, nie jesteś mu winien joba.

Emulacja telefonu to viewport i user agent, dopóki nie masz błędu dotyku. Osobny projekt telefonu na całą suite podwaja rachunek i mało znajduje.

Nocą, nie nigdy

Otagowane testy mogą iść według harmonogramu, nawet gdy nie blokują pull requestu. Awaria WebKit w poniedziałek, której nikt nie widzi do wydania, to skutek zdania „Safari dodamy później”.

- name: WebKit slice
  run: npx playwright test --project=webkit
  if: github.event_name == 'schedule'

Plaster ma być na tyle mały, żeby czerwona noc dała się przeczytać.

Nie debuguj trzech raportów naraz

Awaria tylko w WebKit dostaje trace z WebKit. Awaria we wszystkich trzech to błąd produktu. Napraw ją w Chromium, potem puść otagowane projekty. Gapienie się w trzy raporty HTML tego samego brakującego przycisku marnuje popołudnie, które dodatkowe przeglądarki miały oszczędzić.

Podsumowanie

Chromium chroni merge. Inne silniki chronią defekty, na które masz dowód. Otaguj te testy, odpalaj je według harmonogramu i nie włączaj configu, który puszcza wszystko wszędzie.

Zadanie na ten tydzień: Otwórz błędy z ostatniego kwartału, które zależały od przeglądarki. Otaguj jedną regresję na każdy silnik, który naprawdę wystąpił. Usuń projekt, który nie ma tagu ani ruchu.

Następny wpis w serii: Część 13 — Uprawnienia, których użytkownik odmawia.