De vraag “Playwright of Cypress” komt in Eindhoven meestal op het moment dat een suite pijn doet, niet op het moment dat een team nog niets heeft. Het antwoord begint daarom niet bij een vergelijkingsblog. Het begint bij de repository die maandag rood was. Dit stuk helpt u die keuze te beperken tot wat uw onderhoud aankan, als aanvulling op de module QA Automation en op de contractcontroles in API Testen.
Hebt u al een Cypress-suite die het team kan lezen, blijf dan. Een migratie is een project, geen les. De pijn zit zelden in de merknaam en vaker in selectors die aan CSS hangen, in een gedeeld account en in een job die niemand opent. Die drie repareert u in het framework dat u hebt. Pas wanneer de traces bij een falende UI-test ontbreken en het team JavaScript of TypeScript al schrijft, is een overstap naar Playwright een gesprek. Niet eerder, en niet omdat een conferentie het zo deed.
Hebt u nog niets, kijk dan naar drie dingen. Ten eerste de taal die de ontwikkelaars reviewen: een test die zij niet durven aan te raken, sterft. Ten tweede de vraag of u de browsercontext en een netwerkspoor wilt zien wanneer een klik faalt. Ten derde of de API-controles in dezelfde pipeline kunnen leven. UI-tests zijn de duurste laag. Een team dat zijn contract niet geautomatiseerd heeft en wel vijftig schermpaden, kiest het verkeerde probleem, welk framework er ook op de factuur staat.
Selectors maken of breken beide tools. Een rol en een toegankelijke naam overleven een refactor beter dan een pad van divs. Vaste wachttijden verbergen een race en keren in beide runners terug. Testdata die tests delen, laten de een slagen en de ander falen zonder dat het product veranderde. Die fouten zijn van het team, niet van het framework. In de training op Strijp-S herschrijven wij daarom eerst drie bestaande tests, voordat iemand een nieuw project initialiseert.
Besluit daarna in één zin, in het voorstel of in de strategiepagina: dit team schrijft UI-tests in dit framework, API-tests ernaast, en een tweede framework komt er niet bij tenzij de eerste zin herzien is. Twee stacks naast elkaar zijn geen risicospreiding. Zij zijn twee manieren om dezelfde flaky test te onderhouden. Kies, schrijf de zin op, en meet de suite aan een schone runner. Al het andere is smaak. Een keuze die u niet in de strategiepagina terugvindt, is volgende maand weer een discussie, en die discussie kost meer dan het framework.