Para w stabilnym VS Code, nie preview z maja
Jest 15 kwietnia. W maju 2023 Copilot Chat siedział w VS Code Insiders, za waitlistą i za rozszerzeniem Nightly. Dziś otwieram stabilny edytor, ten sam, w którym od czerwca 2022 mam ghost text, i z boku mam Chat, który jest w ogólnej dostępności od 29 grudnia. Obok czatu mam otwarty spec @playwright/test na pinie 1.43.1 z 12 kwietnia. To jest para przy E2E, o której jest ten wpis. To nie jest drugie intro Chatu i nie jest most od issue do pull requesta, który Universe zapowiedziało na 2024.
Moja teza na kwiecień 2024 jest wąska. Pair programming przy teście przeglądarkowym wygląda tak: Chat szkicuje krok i asercję, ja odpalam npx playwright test i odrzucam zmyślony data-testid. Ownerem asercji zostaję ja, tak jak przy ghost texcie w kwietniu 2023. Chat nie jest właścicielem suite. W styczniu pisałem, że pętla z celem też nim nie jest. Różnica kwietnia jest narzędziem: nie daję modelu celu “napraw test”, tylko rozmawiam o otwartym specu i o helperze obok.
Stan warsztatu na dziś. Runner to Playwright 1.43.1. Component testing nadal jest experimental i nie jest tematem tej pary; o CT pisałem w sierpniu. Chat mam w stabilnym VS Code. Gdy helper siedzi w innym pliku niż spec, dokładam @workspace, żeby czat zebrał referencje, i nadal sam decyduję, który plik ruszyć. Nie mam preview produktu, który prowadziłby zmianę od zgłoszenia do PR, i nie będę udawał, że mam.
Czego tu nie będzie. Nie będzie zdania, że Chat jest nadal na waitliście. Nie będzie tutoriala agenta, który sam dopina patcha do issue. Nie będzie inita projektu od zera, bo pierwszy projekt Playwright i decyzję Playwright zamiast Cypressa mam za sobą od 2022. Będzie syntetyczny spec logowania, dwie propozycje z sidebara i skreślenia.
Co wklejam do pary
Otwieram trzy rzeczy i nic z .env.
Pierwsza to login.spec.ts. Happy path już jest: poprawne hasło, getByRole('button', { name: 'Zaloguj' }), asercja na heading pulpitu. Druga to kawałek POM, LoginPage.ts, bo lokatory nie powinny mieszkać w specu, jeśli używam ich w dwóch scenariuszach. Trzecia to kryterium w jednym zdaniu: złe hasło zostawia formularz i pokazuje alert “Nieprawidłowe hasło”.
Gdy Chat widzi tylko spec, zgaduje POM. Dlatego przy pytaniu o drugi scenariusz dokładam @workspace, albo wklejam sygnaturę klasy strony, jeśli chcę węższy kontekst. Nie wklejam connection stringów, tokenów ani prawdziwych haseł użytkowników testowych. Para, która wymaga sekretu w czacie, nie jest parą, której używam.
Pytanie, od którego zacząłem ten tydzień, brzmiało tak:
W login.spec.ts mam tylko happy path. Dodaj scenariusz złego hasła.
Alert ma rolę alert i tekst "Nieprawidłowe hasło".
Nie używaj waitForTimeout. Zostaw POM, jeśli metoda już tam jest.Odpowiedź przychodzi jako szkic w sidebarze, nie jako commit.
Pętla pary
Pętla ma cztery kroki i żaden z nich nie jest “zastosuj i zapomnij”.
Pierwszy: Chat proponuje locator i expect. Czytam to jak review kolegi, nie jak kod, który już jest mój.
Drugi: wklejam zaakceptowany fragment do specu i odpalam npx playwright test login.spec.ts. Auto-waiting Playwrighta zostaje. Nie proszę Chatu o waitForTimeout, bo sleep, który “naprawia” race, ukrywa, na co właściwie czekamy.
Trzeci: przy padce otwieram trace. Szukam, czy alert był w DOM, czy był hidden, czy tekst siedział w aria-live zamiast w role=alert. Tego Chat nie widzi. Widzi plik.
Czwarty: wracam do sidebara z komunikatem błędu i z jednym zdaniem, czego nie robić. Nie piszę “napraw jakoś”. Piszę “testid login-error nie istnieje, użyj roli”. Im ciaśniejszy powrót, tym mniej Chatu zostaje miejsca na drugi wymysł.
To nie jest agent z pętlą narzędzi. To jest para, w której runner i trace są moje.
Gdzie Chat kłamie przy E2E
Dwie propozycje z tego tygodnia, obie ze syntetycznego logowania, obie do skreślenia.
Skreślenie pierwsze: zmyślony data-testid. Chat dopisał page.getByTestId('login-error'). W komponencie, w POM i w DOM z trace nie ma takiego atrybutu. Model wstawił go, bo w innych repozytoriach alerty błędu mają stabilny testid, i to jest statystycznie dobra zgadywanka. Efekt jest taki, że test czeka na element, który nigdy nie powstanie, i pada timeoutem, który wygląda jak flake środowiska. Asercja, która przechodzi, to getByRole('alert') plus toHaveText('Nieprawidłowe hasło'). Role jest w HTML. Testid jest w wyobraźni modelu.
Skreślenie drugie: API, którego nie ma na 1.43. W drugim szkicu Chat zaproponował toHaveAccessibleName jako skrót na ten sam alert. Na pinie 1.43.1 tej asercji nie mam. Runner, nie czat, jest źródłem prawdy o API. Gdybym wkleił ten wiersz, dostałbym TypeScript albo runtime, zanim dostałbym werdykt o haśle. Zostaję przy getByRole i toHaveText, które znam z runnera, który naprawdę odpalam.
Obok tych dwóch pojawia się jeszcze odruch, który znam z ghost textu: asercja na tekst marketingowy z hero strony logowania zamiast na rolę alertu. Taki expect(page.getByText('Witaj z powrotem')).toBeVisible() przechodzi niezależnie od hasła. To nie jest test błędu. To jest test, że strona się wyrenderowała.
Czego nie deleguję
Chat przyspiesza pierwszy szkic speca. Nie przyspiesza decyzji, czy ten scenariusz w ogóle zasługuje na E2E.
Złe hasło na formularzu logowania jest dla mnie bramką, nie nocnym przebiegiem całej aplikacji, i tę granicę rozpisałem we wrześniu 2022. Czy ten przypadek ma żyć jako test przeglądarkowy, czy jako jednostka na reducerze komunikatu, to pytanie do piramidy, nie do sidebara. CT experimental nie wchodzi do tej pary: nie mieszam montażu komponentu z E2E logowania tylko dlatego, że Chat zna oba API.
SWE-agent z 2 kwietnia odnotowuję jednym zdaniem jako research issue-do-patcha; nie instaluję go i nie robię z niego daily przy specu. Claude 3 zostaje w czacie w przeglądarce. Parą przy E2E jest Copilot w edytorze, bo widzi plik, który mam otwarty.
Podsumowanie
W kwietniu 2024 para przy E2E to Copilot Chat GA przy otwartym specu Playwright 1.43. Szkic powstaje w sidebarze. Zielone sprawdza runner. Merge podpisuje człowiek.
Trzy zdania, które chcę móc przeczytać za rok. Chat w stabilnym VS Code szkicuje drugi scenariusz logowania szybciej niż ja sam klepię boilerplate, i to jest realny zysk względem maja 2023. Dwa szkice z tego tygodnia trzeba było skreślić: testid, którego nie ma, i asercję z API, którego nie ma na 1.43.1. Pętla pary kończy się odpaleniem testu i trace, nie przyciskiem “apply”.
Czego z tego nie wynika. Nie wynika, że wracam do Insidersa, bo GA z 29 grudnia jest dokładnie tym, czego w maju brakowało: ten sam edytor co reszta roboty. Nie wynika, że Chat może sam uznać spec za zielony. Nie wynika też, że most issue-plan-PR już u mnie działa, bo go nie mam.
Warunek, po którym poznam, że para dojrzała, formułuję tak: dwa szkice pod rząd na tym samym kryterium używają roli, która jest w DOM, i API, które jest w 1.43.1. Do tego czasu szkicuję z Chatem i merguję sam.