Zielone E2E, puste pytanie o pojemność
Jest 15 września. Mam zielone logowanie na Playwright i nadal nie wiem, czy checkout przeżyje pięćdziesiąt równoległych sesji HTTP. We wrześniu 2022 rozdzieliłem bramkę, main i nightly. Dziś dokładam k6 do nightly, nie przepisuję piramidy i nie zrzucam E2E z PR.
Moja teza na wrzesień 2024 jest wąska. k6 (protocol plus stabilny k6/browser) mierzy czas i obciążenie. Playwright 1.47.1 z 13 września zostaje ownerem asercji funkcyjnych. API k6 jest zgrubnie jak Playwright. To nie jest drop-in i nie zastępuje suite E2E na PR.
Stan warsztatu. k6 OSS stoi na 0.53.0 z 13 sierpnia. k6/browser wyszedł z experimental w 0.52.0 25 czerwca; import kanoniczny to k6/browser, nie k6/experimental/browser. Grafana Cloud k6 browser tests są GA od 4 lipca; demo w tym wpisie jest OSS. Runner funkcyjny to Playwright 1.47.1. 12 września, trzy dni temu, OpenAI ogłosiło o1-preview. Zostawiam to jako nagłówek. Nie piszę nim scenariusza loadu.
Czego tu nie będzie. Nie będzie zdania, że k6 zastępuje @playwright/test. Nie będzie pinu 0.54.0 ani 1.47.2. Nie będzie RPS z produkcji ani kwot Grafana Cloud. Nie będzie tutoriala Gatlinga. Będzie syntetyczne API logowania z progiem p95 i jeden skrypt k6/browser z page.goto.
Dwie warstwy k6
Pierwsza warstwa to protocol. HTTP, tanie VU, progi na http_req_duration. Na syntetycznym POST /login ustawiam thresholds: { http_req_duration: ['p(95)<500'] } i iteracje, nie asercję “zobacz dashboard”. Fail loadu to przekroczony próg, nie czerwony expect z trace.
Druga warstwa to przeglądarka. k6/browser odpala prawdziwy Chromium, mało VU, metryki frontend. Klik i page.goto na syntetycznym checkout. To nie jest sto sesji na jednym runnerze GitHub Actions. To jest kilka wirtualnych użytkowników, bo Chromium nie jest tani.
Cloud k6 browser od 4 lipca jest opcją, gdy nie chcę trzymać Chromium na agencie. OSS wystarcza, żeby zobaczyć, że import i API żyją. Nie mieszam tu Testcontainers jako silnika loadu. Kontenery z sierpnia 2022 podnoszą UI. k6 je obciąza osobnym procesem.
Dlaczego nie zlewam z Playwright
Playwright: asercje, trace, POM, trzy silniki, job PR. Od maja 2022 i od decyzji Playwright zamiast Cypressa to jest moja suite funkcyjna. k6: load, thresholds, inny runtime (Sobek, nie Node). Składnia wygląda znajomo. Skryptu 1:1 nie kopiuję.
Grafana sama pisze o zgrubnej zgodności z Playwright, nie o stu procentach parity. getByRole z POM nie wklejam do k6/browser i nie udaję, że dostałem trace. Piramida nie spłaszcza się, bo dwa narzędzia mają podobne page.goto.
VU k6 to nie strategy.parallel z października 2021. Tam równoległość jednostek i jobów. Tu wirtualni użytkownicy obciążenia. Zlanie tych dwóch słów w jednym YAML-u kończy się runnerem, który dusi się Chromium, i raportem, który wygląda jak flake.
Gdzie w triggerach
Smoke protocol może usiąść na main: mało VU, krótki czas, próg, który ma wykryć oczywisty regres p95, nie capacity planning. Load i browser VU idą na nightly albo osobny scheduled. Required check na PR zostaje mały. Tę granicę mam z 2022 i z procesu. Job, który na każdym pushu odpala pięćdziesiąt VU, uczy zespół ignorować czerwony.
Nie dokładam k6 jako required na ścieżce logowania w Playwright. Zielone E2E mówi, że ścieżka działa. k6 mówi, czy jeszcze oddycha pod ruchem.
Pułapki września
Trzy skreślenia z tego tygodnia.
Skreślenie pierwsze: za dużo VU przeglądarki na jednym runnerze. Dwadzieścia Chromium na hosted agencie nie jest testem pojemności aplikacji. Jest testem OOM agenta. Protocol zostaje tani. Browser zostaje wąski.
Skreślenie drugie: asercja funkcyjna w skrypcie loadu. check, że na stronie jest tekst “Witaj”, przy p95 na API logowania, miesza dwa pytania. Albo ścieżka działa (Playwright), albo p95 trzyma (k6). Oba w jednym skrypcie dają czerwony, którego nie umiem przypisać.
Skreślenie trzecie: stary import k6/experimental/browser. Wsparcie experimental ma do 23 września. Na 15 września ten moduł jeszcze istnieje. Pinem jest k6/browser od 0.52. Gdybym skopiował skrypt z wiosny, dostałbym deprecację, zanim dostałbym metrykę.
o1-preview od 12 września nie pisze mi scenariusza. Trzy dni preview, limity, inny koszt. Zostawiam nagłówek. Scenariusz loadu piszę ja, z progiem, który umiem obronić.
Podsumowanie
We wrześniu 2024 k6 mierzy pojemność. Playwright mówi, czy ścieżka działa. Oba na swoich jobach.
Trzy zdania na rok. Protocol na syntetycznym logowaniu pada, gdy p95 wychodzi poza próg, nawet gdy E2E jest zielone. k6/browser na 0.53.0 to kilka VU Chromium, nie zamiennik suite. Required na PR zostaje mały; load siedzi na nightly.
Czego z tego nie wynika. Nie wynika, że kasuję Playwright. Nie wynika, że 0.54.0 już u mnie siedzi. Nie wynika, że o1 optymalizuje wydajność.
Warunek dojrzałości: dwa nightly pod rząd pokazują ten sam próg na protocol i nie wołają “to flake E2E”, gdy k6 jest czerwony, a Playwright zielony.