Migrering av Cypress-tester til Playwright med Copilot

Da vi fikk en forespørsel om å migrere Cypress-tester til Playwright, forventet vi en lang og tidkrevende omskrivingsprosess.Overraskende nok klarte vi, med hjelp fra GitHub Copilot, å starte migreringen fra Cypress til Playwright på bare et par dager — samtidig som vi holdt CI-pipelinen i gang hele tiden uten å forstyrre noen testprosesser.I denne artikkelen vil jeg dele hvordan vi nærmet oss denne migreringen, de erfaringene vi gjorde underveis, og hvordan AI-assistert kode-migrering kan redusere manuell arbeidsinnsats betydelig ved rammeverksoverganger.Prosjektets KontekstProsjektet var en kompleks helsetjeneste-plattform med mye som skjedde under overflaten. Vår testoppsett inkluderte:End-to-end (E2E) og integrasjonstesterEn tilpasset TAF-arkitektur med oppsett, nedbryting og oppretting av enheterMulti-miljøkonfigurasjonerDynamiske data og dyp navigasjonslogikkTotalt hadde vi 148 E2E-tester som kjørte på Cypress — alle fungerte fint, men organisasjonen ønsket å standardisere QA-verktøy på tvers av teamene, noe som betydde én ting: migrering til Playwright.Hvorfor bruke GitHub Copilot for migrering?Da forespørselen om migrering kom inn, så jeg en mulighet til å eksperimentere med GitHub Copilot for testautomatisering. I stedet for å skrive om hundrevis av testfiler manuelt, ønsket jeg å se hvor langt vi kunne presse AI-hjelp til å automatisere syntakskonvertering fra Cypress til Playwright.Og ærlig talt, det fungerte langt bedre enn ventet.GitHub Copilot håndterte det meste av den gjentakende oversettelsen (velgere, kommandoer, asynkron håndtering, osv.), noe som lot oss fokusere på infrastrukturjusteringer og finjusteringer.Innen 1–2 dager hadde vi allerede en fungerende prototype av Playwright-testautomatiseringsrammeverket.To Viktige ForbeholdVerifiser Alltid AI-Generert KodeSelv om AI-assistert kode-migrering gjør ting raskere, må du gjennomgå hver linje. Infrastrukturmigreringer kan lett introdusere subtile feil eller ytelsesregresjoner. Tenk på Copilot som din par-programmerer, ikke som en autopilot.Hold det Gamle Rammeverket I Gang Til SluttAldri blokkere utgivelser eller regresjoner under migreringen. Hold Cypress-testene dine kjørende på CI til de tilsvarende pakkene er fullt stabile i Playwright. Når en pakke er migrert og validert, fjern den fra Cypress og bytt CI til å kjøre den i Playwright.Denne gradvise utrullingen sikrer null nedetid og kontinuerlig testdekning gjennom hele prosessen.Arbeidsflyt for å Migrere fra Cypress til PlaywrightNår grunnlaget var klart, gikk vi over til den praktiske migreringen. Nedenfor er arbeidsflyten som hjalp oss med å kjøre begge rammeverkene parallelt, opprettholde CI-stabilitet, og starte migreringen av tester inkrementelt — uten å blokkere pågående utgivelser.1. Initialiser Playwright og Opprett MappestrukturenDet første steget var å initialisere Playwright og opprette en ren, isolert mappestruktur. Vi ønsket at begge rammeverk skulle leve side om side i det samme depotet, slik at vi kunne kjøre dem samtidig under overgangen.Dette oppsettet lot oss:Migrere gradvisSamligne resultater og tidsbruk mellom Cypress og PlaywrightHolde CI-pipeliner i gang for beggeEksempel på initialisering:Her er den foreslåtte mappestrukturen vi brukte for Playwright:├── cypress/ │ ├── app/ │ ├── downloads/ │ ├── e2e/ │ ├── fixtures/ │ ├── screenshots/ │ ├── support/ │ └── videos/ ├── playwright/ │ ├── app/ │ │ ├── components/ │ │ ├── fixtures/ │ │ └── pageobjects/ │ ├── constants/ │ ├── helpers/ │ ├── reports/ │ ├── test-results/ │ └── tests/ ├── .gitignore ├── package.json ├── playwright.config.ts ├── smoke.config.ts ├── tsconfig.json 2. Konfigurer Separate `tsconfig` Filer for Hvert RammeverkEt av de tidlige problemene vi møtte var TypeScript-konflikter — begge rammeverk definerer lignende metodenavn (`forvente`, `forespørsel`, osv.), og deling av en enkelt `tsconfig.json` førte til kompilasjonsfeil.Løsningen var enkel: del TypeScript-konfigureringene. Denne strukturen sikrer at hvert rammeverk initialiserer sine egne type-definisjoner og unngår type-kollisjoner:├── tsconfig.json ├── tsconfig.cypress.json ├── tsconfig.playwright.json Hoved tsconfig.jsonLegg til `kompositt`-alternativet for å støtte prosjektreferanser.tsconfig.jsonjson { "compilerOptions": { "composite": true } } tsconfig.cypress.jsonjson { "extends": "./tsconfig.json", "compilerOptions": { "types": ["cypress", "@testing-library/cypress", "node"], "isolatedModules": false }, "include": ["cypress/**/*.ts"] } tsconfig.playwright.jsonjson { "extends": "./tsconfig.json", "compilerOptions": { "types": ["node", "@playwright/test"] }, "include": ["playwright/**/*.ts", "playwright.config.ts"] } Med denne separasjonen på plass, kunne begge rammeverkene sameksistere fredelig i ett repo — ingen flere kompilator-konflikter og ingen risiko for utilsiktet initialisering av delte metoder to ganger.3. Opprett en Prompt for å Automatisere Migrasjon med GitHub CopilotNår Playwright var initialisert og prosjektet var strukturert, var det på tide å la GitHub Copilot hjelpe med det tunge løftet.For å gjøre dette, opprettet vi en tilpasset prompt som definerer hvordan Copilot skal opptre når den omskriver tester fra Cypress til Playwright. Prompten forteller agenten hva den skal gjøre, hvordan den skal gjøre det, og hva den skal ignorere — noe som gir konsekvente resultater på tvers av alle migreringer.Hvordan Legge til PromptenInne i GitHub-repoet ditt, åpne Gear-ikonet ⚙️ i Copilot Chat og opprett en ny prompt. Filene vil bli lagret automatisk under: `./github/prompts/`Du kan gi den et navn som `migrer_tester.md`.Eksempel på prompt:--- mode: agent --- Du er en Playwright Test-generator, en ekspert innen nettleserautomatisering og end-to-end testing. Din spesialitet er å lage robuste, pålitelige Playwright-tester som nøyaktig simulerer brukerinteraksjoner og validerer applikasjonsoppførsel. Din oppgave er å hjelpe med å migrere eksisterende Cypress-tester til Playwright-tester. Cypress-testene, sideobjekt, komponenter og hjelpefiler blir gitt som input, og du må generere ekvivalent Playwright-testkode. Utskrift ALL migrert kode til chatten. Når du genererer Playwright-testkoden eller eventuelle sideobjekter, må du sørge for at:

Teststrukturen følger samme struktur som Cypress-testene. Opprett et globalt fixture for oppsett og nedbryting og gjenbruk det i testene. Alle brukerinteraksjoner (klikk, skriving, navigasjon) blir nøyaktig oversatt til Playwright-syntaks i sideobjekter og testfiler. Påstander i Cypress blir konvertert til ekvivalente Playwright-krav. Ignorer nettverks-spionering og stubbing-deler av Cypress-testene. Kommenter ut alle metodene med venting (f.eks. cy.wait) i Playwright-koden. Ikke bruk get-metoder i sideobjekter; bruk direkte metoder i stedet backbackItem = () =&gt; this.page.locator('[id="item_4_title_link"]');

Hvorfor Dette HjelperEn slik strukturert prompt tillater GitHub Copilot å opptre mer som en spesialisert migreringsassistent, ikke en generell kodegenerator.Med riktig kontekst og regler, kan Copilot automatisk:Omskrive store deler av Cypress-tester til Playwright-syntaksOpprettholde konsekvens i mappestrukturen og teststrukturen Redusere manuell konverteringstid med 70–80%I essens, du lager din egen AI-migrasjonsverktøykjede — skreddersydd til prosjektets struktur og konvensjoner.4. Velg Agentmodus og Kjør Migreringen Trinn-for-TrinnNår prompten var klar, var neste steg å faktisk kjøre migreringen med GitHub Copilot i agentmodus. I denne fasen lot vi AI-modellen prosessere hver fil — sideobjekter, komponenter, hjelpere, og til slutt testene — én etter én.For denne oppgaven brukte vi GPT-4.1-modellen, som gir de mest konsistente og kontekstsensitive kode-transformasjonene.Hvordan Starte Migrering1. Åpne Copilot Chat i VS Code2. Bruk / for å velge promptfilen du opprettet tidligere3. Bruk # for å velge en spesifikk fil (for eksempel, en Cypress-test eller sideobjekt) som du ønsker å migrereCopilot vil nå bruke migreringsprompten din og generere en Playwright-kompatibel versjon av filen direkte i chatten.Eksempel på migrering av inventoryPage Sideobjektts Cypress import { ItemComponent } from "../components/item.component"; import Common from "./common"; class InventoryPage extends Common { item = new ItemComponent(); backbackItem = () => cy.get("#item_4_title_link"); backbackAddItemButton = () => cy.getByTestId("add-to-cart-sauce-labs-backpack"); bikeLightsAddItemButton = () => cy.getByTestId("add-to-cart-sauce-labs-bike-light"); backbackRemoveItemButton = () => cy.getByTestId("remove-sauce-labs-backpack"); shoppingCartLogo = () => cy.get("#shopping_cart_container"); clickBackbackAddItemButton = () => this.backbackAddItemButton().click(); clickBikeLightsAddItemButton = () => this.bikeLightsAddItemButton().click(); clickBackbackRemoveItemButton = () => this.backbackRemoveItemButton().click(); assertCartLogoItems = (itemsNum: number) => this.shoppingCartLogo().should("have.text", itemsNum); } export default new InventoryPage(); ts Playwright import { Page, Locator, expect } from "@playwright/test"; import Common from "./common"; class InventoryPage extends Common { constructor(page: Page) { super(page); this.item = new ItemComponent(page); } // Lokatorer backbackItem(): Locator { return this.page.locator("#item_4_title_link"); } backbackAddItemButton(): Locator { return this.page.getByTestId("add-to-cart-sauce-labs-backpack"); } bikeLightsAddItemButton(): Locator { return this.page.getByTestId("add-to-cart-sauce-labs-bike-light"); } backbackRemoveItemButton(): Locator { return this.page.getByTestId("remove-sauce-labs-backpack"); } shoppingCartLogo(): Locator { return this.page.locator("#shopping_cart_container"); } // Handlinger async clickBackbackAddItemButton(): Promise { await this.backbackAddItemButton().click(); } async clickBikeLightsAddItemButton(): Promise { await this.bikeLightsAddItemButton().click(); } async clickBackbackRemoveItemButton(): Promise { await this.backbackRemoveItemButton().click(); } async assertCartLogoItems(itemsNum: number): Promise { await expect(this.shoppingCartLogo()).toHaveText(String(itemsNum)); } } export default InventoryPage; Finjustering av Agentens AtferdIkke bekymre deg hvis den første utdataen ikke er perfekt. Fra vår erfaring får AI-agenten vanligvis 60–70 % av koden riktig ved første forsøk. Nøkkelen er å holde samtalekonteksten aktiv — fortsett å raffinere den samme chattråden ved å be om rettelser eller justeringer. Når du gjør dette, begynner Copilot å lære prosjektmønstrene dine og produserer mer nøyaktig, gjenbrukbar kode.I essens, jo flere iterasjoner du gjør i samme chat, jo bedre blir migreringskvaliteten.Migreringsrekkefølge: Filer Først, Så TesterFor å holde avhengigheter konsistente og unngå manglende referanser, følg denne rekkefølgen:1. Generer ikke-testfiler først:SideobjekterKomponenterHjelpefilerKonstanter2. Når alle støttefiler er generert og verifisert, legg til #app-mappen i chat-konteksten, og migrer deretter testfilene selv.VerifikasjonstrinnNår en Playwright-test er generert:1. Gå gjennom koden — bekreft at sidens lokatorer, testtrinn og påstander er riktige.2. Kjør testen ved hjelp av Playwright CLI for å sikre at den utføres riktig.3. Fiks mindre syntaks- eller fixture-tilpasninger hvis Copilot misforstod en Cypress-kommando.Ved å verifisere etter hver fil holder du migreringen stabil og inkrementell, og unngår omfattende feilsøking senere.Eksempel på migrert inventoryPage test som er vellykket bestått:ts Cypress import inventoryPage from "cypress/app/pageobjects/inventoryPage"; import loginPage from "cypress/app/pageobjects/loginPage"; import { itemsNames } from "../../fixtures/data.json"; describe("InventoryPage tester", () => { beforeEach(() => { loginPage.loginWithValidData(); }); it("Brukeren skal legge til gjennstanden i handlekurven", () => { inventoryPage.item.itemByName("Bike Light").should("have.text", itemsNames.bikeLight); inventoryPage.item.addToCartByName("Bike Light"); inventoryPage.assertCartLogoItems(1); }); it("Brukeren skal fjerne gjennstanden fra handlekurven", () => { inventoryPage.backbackItem().should("have.text", itemsNames.backpackItemName); inventoryPage.clickBackbackAddItemButton(); inventoryPage.assertCartLogoItems(1); inventoryPage.clickBackbackRemoveItemButton(); inventoryPage.shoppingCartLogo().should("not.have.text"); }); it("Brukeren skal legge til flere gjenstander i handlekurven", () => { inventoryPage.backbackItem().should("have.text", itemsNames.backpackItemName); inventoryPage.clickBackbackAddItemButton(); inventoryPage.assertCartLogoItems(1); inventoryPage.clickBikeLightsAddItemButton(); inventoryPage.assertCartLogoItems(2); }); }); ts Playwright import { test, expect } from "../fixtures/test.fixture"; import { itemsNames } from "../../constants/data.json"; // InventoryPage tester migrert fra Cypress til Playwright test.describe("InventoryPage tester", () => { test.beforeEach(async ({ pageManager }) => { await pageManager.loginPage.loginWithValidData(); }); test("Brukeren skal legge til gjennstanden i handlekurven", async ({ pageManager }) => { await expect( pageManager.inventoryPage.item.itemByName(itemsNames.bikeLight)).toHaveText(itemsNames.bikeLight); await pageManager.inventoryPage.item.addToCartByName(itemsNames.bikeLight); await pageManager.inventoryPage.assertCartLogoItems(1); }); test("Brukeren skal fjerne gjennstanden fra handlekurven", async ({ pageManager }) => { await expect( pageManager.inventoryPage.backbackItem()).toHaveText(itemsNames.backpackItemName); await pageManager.inventoryPage.clickBackbackAddItemButton(); await pageManager.inventoryPage.assertCartLogoItems(1); await pageManager.inventoryPage.clickBackbackRemoveItemButton(); await expect(pageManager.inventoryPage.shoppingCartLogo()).not.toHaveText(/\d/); // Burde ikke ha noen talltekst }); test("Brukeren skal legge til flere gjenstander i handlekurven", async ({ pageManager }) => { await expect(pageManager.inventoryPage.backbackItem()).toHaveText(itemsNames.backpackItemName); await pageManager.inventoryPage.clickBackbackAddItemButton(); await pageManager.inventoryPage.assertCartLogoItems(1); await pageManager.inventoryPage.clickBikeLightsAddItemButton(); await pageManager.inventoryPage.assertCartLogoItems(2); }); }); 5. Endelig Mappestruktur Etter MigreringNår migreringen var fullført, nådde vårt depot en stabil, dobbel-rammeverksstatus — fullt kjørende både Cypress og Playwright side om side. Denne strukturen lot oss:Gradvis avvikle Cypress-testpakker etter hvert som de ble erstattetHolde CI/CD-pipeliner operative for begge rammeverkOpprettholde en ren og modulær arkitekturNedenfor er den endelige strukturen etter fullføring av migreringsarbeidsflyten.Endelig Mappestruktur├── .env ├── .gitignore ├── readme.md ├── package.json ├── playwright.config.ts ├── smoke.config.ts ├── tsconfig.cypress.json ├── tsconfig.playwright.json ├── tsconfig.json ├── .github/ │ ├── prompts/ │ └── workflows/ ├── cypress/ │ ├── app/ │ ├── downloads/ │ ├── e2e/ │ ├── fixtures/ │ ├── screenshots/ │ ├── support/ │ └── videos/ ├── playwright/ │ ├── app/ │ ├── constants/ │ ├── helpers/ │ ├── reports/ │ ├── test-results/ │ └── tests/ Merknader om Strukturen.github/prompts/ — inneholder dine Copilot-migreringsprompts. Å holde disse versjonerte gjør at du kan oppdatere eller gjenbruke dem for fremtidige rammeverks migreringer eller omstruktureringer..github/workflows/ — holder dine CI/CD-definisjoner. Du kan kjøre både Playwright- og Cypress-jobber parallelt til full avvikling av det gamle rammeverket.playwright/-mappen — fungerer nå som den primære automatiseringskilden fremover. Den speiler strukturen til den tidligere Cypress-implementeringen for å lette onboarding og sikre konsistens.tsconfig.playwright.json og tsconfig.cypress.json — forblir separate for full type-isolasjon, og forhindrer konflikter under bygging.Denne strukturen støttet ikke bare en smidig overgang, men posisjonerte prosjektet for fremtidig skalerbarhet, CI-fleksibilitet, og modulært testansvar på tvers av team.Praktiske Råd & LærdommerEtter å ha migrert nesten 150 tester med Copilot og Playwright, her er noen viktige lærdommer og tips som gjorde prosessen jevnere (og reddet oss fra noen hodepiner).Generelle AI-Relaterte RådAI lyver — ofte overbevisende. Verifiser alltid hver linje med kode som AI genererer. Stol aldri blindt på det, spesielt under infrastrukturmigreringer.Hold deg til konsekvente navnekonvensjoner.Behold identiske variabel- og metodenavn på tvers av rammeverk — det hjelper AI-agenten med å migrere kode mer nøyaktig og gjør det enklere for deg å finne og importere dem senere.Bygg imports manuelt.Copilot har en tendens til å rote til importveier. Det er ofte raskere å slette dem og importere på nytt manuelt, eller sette opp globale importer som: import x from "playwright/foo/bar";

Gjenbruk samme chat for alle migreringer. Hold deg til en enkelt Copilot-chattråd — det bygger kontekst og "husker" prosjektkonvensjonene dine, noe som fører til bedre resultater.

Dekomponer migreringstasker. Generer 1–2 filer om gangen. Mindre oppgaver gir mer nøyaktige utdata og gjør manuell validering enklere.

Playwright-Spesifikke Råd Aldri opprett flere instanser av det samme Sideobjektet uten behov. Å gjøre dette kan forårsake inkonsistent tilstand eller ødelagte velgere når du navigerer mellom sider. Løsningen? Implementer en Sidebehandler som holder alle sideobjektene tilgjengelige gjennom en enkelt instans.

Her er et minimalt eksempeloppsett:

ts // login.page.ts class LoginPage extends Common { async clickLoginButton(): Promise { await this.loginButton().click(); } } export default LoginPage; //----------------------------------------------------------- //PageManager.ts export class PageManager { readonly loginPage: LoginPage; constructor(page: Page) { this.loginPage = new LoginPage(page); } } //----------------------------------------------------------- //test.fixture.ts export const test = base.extend ({ pageManager: async ({ page }, use) => { const manager = new PageManager(page); await use(manager); }, }); export { expect }; //----------------------------------------------------------- //userLogin.spec.ts test("Brukeren skal logge inn med gyldige data", async ({ pageManager }) => { await pageManager.loginPage.clickLoginButton(); }); Andre Tekniske TipsFjern alle "get" prefikser fra lokatorer som AI-agenten genererer — bruk direkte lokatormetoder i stedet.Ikke glem å konfigurere dotenv for miljøvariabler og legitimasjon.Tilpass Playwright-konfigurasjonen din for å utveksle alle rapporter under Playwright-mappen, slik at prosjektroten forblir ren:ts reporter: [["html", { open: "never", outputFolder: "./playwright/reports/" }]], outputDir: "./playwright/test-results", EtterordJeg inkluderte ikke ESLint-oppsett her siden det varierer fra prosjekt til prosjekt. Den eneste universelle anbefalingen jeg kan gi er å installere Playwright ESLint-pluginen for bedre regelhåndheving:eslint-plugin-playwrightHvis du vil utforske et komplett fungerende eksempel på denne migreringen — inkludert promptfiler, tsconfigs, og CI-oppsett — kan du sjekke det fullstendige depotet her:Repo eksempel