Migrering af Cypress-tests til Playwright med Copilot

Da vi fik en anmodning om at migrere Cypress-tests til Playwright, forventede vi en lang, kedelig omskrivningsproces.Overraskende nok lykkedes det os med hjælp fra GitHub Copilot at starte migrationen fra Cypress til Playwright på kun et par dage — og holde vores CI-pipeline kørende hele tiden uden at afbryde nogen testprocesser.I denne artikel vil jeg dele, hvordan vi greb denne migration an, de lektioner vi lærte undervejs, og hvordan AI-assisteret kode migration drastisk kan reducere den manuelle arbejdsbyrde ved overgange mellem rammer.Projekt KontekstProjektet var en kompleks sundhedsplatform med meget der foregik under overfladen. Vores testopsætning omfattede:End-to-end (E2E) og integrationstestsEn brugerdefineret TAF-arkitektur med opsætninger, nedlægninger og oprettelse af enhederMulti-miljøkonfigurationerDynamiske data og dyb navigationslogikI alt havde vi 148 E2E-tests, der kørte på Cypress — alle fungerede fint, men organisationen ønskede at standardisere QA-værktøjer på tværs af teams, hvilket betød én ting: Playwright-migrering.Hvorfor Bruge GitHub Copilot til Migration?Da migrationsanmodningen kom ind, så jeg en mulighed for at eksperimentere med GitHub Copilot testautomatisering. I stedet for manuelt at omskrive hundreder af testfiler, ville jeg se, hvor langt vi kunne presse AI-assistance til at automatisere syntaksomdannelse fra Cypress til Playwright.Og ærligt talt, det fungerede langt bedre end forventet.GitHub Copilot håndterede det meste af den gentagne oversættelse (vælgere, kommandoer, async håndtering osv.), hvilket lod os fokusere på infrastrukturjusteringer og finjusteringer.Inden for 1-2 dage havde vi allerede en fungerende prototype af Playwright testautomatiseringsrammeverket.To Vigtige AnsvarsfraskrivelserVerificer Altid AI-genereret KodeSelvom AI-assisteret kode migration fremskynder tingene, skal du gennemgå hver linje. Infrastrukturmigreringer kan nemt introducere subtile fejl eller præstationsregressioner. Tænk på Copilot som din makkerprogrammer, ikke en autopilot.Hold den Gamle Ramme Kørende Indtil SlutningenAldrig blokere udgivelser eller regressioner under migration. Hold dine Cypress-tests kørende på CI, indtil de tilsvarende sæt er helt stabile i Playwright. Når et sæt er migreret og valideret, fjern det fra Cypress og skift CI til at køre det i Playwright.Denne gradvise implementering sikrer nul nedetid og kontinuerlig testdækning gennem hele processen.Workflow til at Migrere fra Cypress til PlaywrightNår fundamentet var klart, gik vi over til den praktiske migrering. Nedenfor er workflowet, der hjalp os med at køre begge rammer parallelt, opretholde CI-stabilitet og begynde at migrere tests trinvis — uden at blokere igangværende udgivelser.1. Initialiser Playwright og Opret MappestrukturenDet første skridt var at initialisere Playwright og oprette en ren, isoleret mappestruktur. Vi ønskede, at begge rammer skulle leve side om side i det samme repository, så vi kunne udføre dem samtidigt under overgangen.Den opsætning gav os mulighed for:At migrere gradvistAt sammenligne resultater og tidspunkter mellem Cypress og PlaywrightAt holde CI-pipelines kørende for beggeInitialisering eksempel:Her er den foreslåede mappestruktur, vi brugte til 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 Hver RammeEt af de tidlige problemer, vi stod overfor, var TypeScript-konflikter — begge rammer definerer lignende metode navne (`expect`, `request`, osv.), og deling af en enkelt `tsconfig.json` førte til kompilationsfejl.Løsningen var enkel: del TypeScript-konfigurationerne. Denne struktur sikrer, at hver ramme initialiserer sine egne type-definitioner og undgår typekollisioner:├── tsconfig.json ├── tsconfig.cypress.json ├── tsconfig.playwright.json Hoved tsconfig.jsonTilføj `composite`-muligheden for at understøtte projekt-referencer.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 adskillelse på plads kunne begge rammer eksistere fredeligt i et repo — ikke flere compiler konflikter og ingen risiko for ved et uheld at initialisere delte metoder to gange.3. Opret en Prompt til at Automatisere Migration med GitHub CopilotNår Playwright var initialiseret og projektet var struktureret, var det tid til at lade GitHub Copilot hjælpe med det tunge arbejde.For at gøre dette, oprettede vi en brugerdefineret prompt, der definerer, hvordan Copilot skal opføre sig, når den omskriver tests fra Cypress til Playwright. Prompten fortæller agenten, hvad man skal gøre, hvordan man skal gøre det, og hvad man skal ignorere — hvilket giver konsistente resultater på tværs af alle migrationer.Sådan Tilføjer Du PromptenInden for dit GitHub-repository, åbn Gear-ikonet ⚙️ i Copilot Chat og opret en ny prompt. Fil vil automatisk blive gemt under: `./github/prompts/`Du kan navngive den noget som `migrate_tests.md`.Prompt eksempel:--- mode: agent --- Du er en Playwright Test Generator, en ekspert i browserautomatisering og end-to-end testning. Din specialitet er at skabe robuste, pålidelige Playwright-tests, der nøjagtigt simulerer brugerinteraktioner og validerer applikationsadfærd. Din opgave er at hjælpe med at migrere eksisterende Cypress-tests til Playwright-tests. Cypress-tests, sideobjekter, komponenter og hjælpefiler gives som input, og du skal generere ækvivalente Playwright-testkoder. Output ALLE migrerede koder til chatten. Når der genereres Playwright testkode eller ethvert sideobjekt, skal du sikre dig, at:

Teststrukturen følger den samme struktur som Cypress-tests. Opret en global fixture til opsætning og nedlægning og genbrug den i testene. Alle brugerinteraktioner (klik, skrivning, navigation) oversættes nøjagtigt til Playwright-syntaks i sideobjekter og testfiler. Påstande i Cypress konverteres til ækvivalente Playwright-påstande. Ignorer netværksspy og stub-delen af Cypress-tests. Kommenter alle metoder med ventetider (f.eks. cy.wait) i Playwright-koden. Brug ikke get metoder i sideobjekter; brug direkte metoder i stedet backbackItem = () =&gt; this.page.locator('[id="item_4_title_link"]');

Hvorfor Dette HjælperDenne type struktureret prompt gør det muligt for GitHub Copilot at opføre sig mere som en specialiseret migrationsassistent, ikke en generel kodegenerator.Med den rigtige kontekst og regler kan Copilot automatisk:Omskrive store mængder Cypress-tests til Playwright-syntaksOpretholde konsistens i mapper og teststruktur Reducere den manuelle konverteringstid med 70-80%Essentielt set skaber du din egen AI-migrationsværktøjslinje — tilpasset til dit projekts struktur og konventioner.4. Vælg Agenttilstand og Kør Migrationen Trin-for-TrinNår prompten var klar, var næste skridt faktisk at køre migrationen med GitHub Copilot i agenttilstand. I denne fase lod vi AI-modellen behandle hver fil — sideobjekter, komponenter, hjælpere, og til sidst tests — én ad gangen.Til denne opgave brugte vi GPT-4.1-modellen, som leverer de mest konsistente og kontekstbevidste kodeomdannelser.Sådan Starter Du Migration1. Åbn Copilot Chat i VS Code2. Brug / til at vælge det promptfil, du oprettede tidligere3. Brug # til at vælge en specifik fil (for eksempel en Cypress-test eller sideobjekt), som du ønsker at migrereCopilot vil nu anvende din migrationsprompt og generere en Playwright-kompatibel version af filen direkte i chatten.Eksempel på migration af 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 af Agentens AdfærdBliv ikke bekymret, hvis den første output ikke er perfekt. Ud fra vores erfaring får AI-agenten normalt 60–70 % af koden rigtigt ved første forsøg. Nøglen er at holde samtale konteksten aktiv — fortsæt med at finjustere den samme chattråd ved at bede om rettelser eller justeringer. Når du gør dette, begynder Copilot at lære dine projektmønstre og producerer mere præcise, genanvendelige koder.Essentielt set bliver kvaliteten af migrationen bedre, jo flere iterationer du laver i den samme chat.Migrationsrækkefølge: Filer Først, Så TestsFor at holde afhængighederne konsistente og undgå manglende referencer, følg denne rækkefølge:1. Generer ikke-testfiler først:SideobjekterKomponenterHjælpefilerKonstanter2. Når alle supportfiler er genereret og verificeret, tilføj #app mappen til chat-konteksten, så migrere testfilerne selv.VerifikationsskridtNår en Playwright-test er genereret:1. Gennemgå koden — bekræft, at side-lokatorer, testtrin og påstande er korrekte.2. Kør testen ved hjælp af din Playwright CLI for at sikre, at den fungerer korrekt.3. Fix mindre syntaks eller fixture uoverensstemmelser, hvis Copilot misforstod en Cypress-kommando.Ved at verificere efter hver fil holder du migrationen stabil og trinvis, og undgår større fejlretning senere.Eksempel på migreret inventoryPage test som nu passerer med succes:ts Cypress import inventoryPage from "cypress/app/pageobjects/inventoryPage"; import loginPage from "cypress/app/pageobjects/loginPage"; import { itemsNames } from "../../fixtures/data.json"; describe("InventoryPage tests", () => { beforeEach(() => { loginPage.loginWithValidData(); }); it("Brugeren skal tilføje varen til kurven", () => { inventoryPage.item.itemByName("Bike Light").should("have.text", itemsNames.bikeLight); inventoryPage.item.addToCartByName("Bike Light"); inventoryPage.assertCartLogoItems(1); }); it("Brugeren skal fjerne varen fra kurven", () => { inventoryPage.backbackItem().should("have.text", itemsNames.backpackItemName); inventoryPage.clickBackbackAddItemButton(); inventoryPage.assertCartLogoItems(1); inventoryPage.clickBackbackRemoveItemButton(); inventoryPage.shoppingCartLogo().should("not.have.text"); }); it("Brugeren skal tilføje flere varer til kurven", () => { 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 tests migreret fra Cypress til Playwright test.describe("InventoryPage tests", () => { test.beforeEach(async ({ pageManager }) => { await pageManager.loginPage.loginWithValidData(); }); test("Brugeren skal tilføje varen til kurven", 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("Brugeren skal fjerne varen fra kurven", 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/); // Skal ikke have nogen tal }); test("Brugeren skal tilføje flere varer til kurven", 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. Slut Repository Struktur Efter MigrationNår migrationen var afsluttet, nåede vores repository en stabil, dual-rammestyre — kørte fuldt ud både Cypress og Playwright side om side. Denne struktur gjorde det muligt for os at:Gradvis udfase Cypress test sæt, efterhånden som de blev erstattetHolde CI/CD-pipelines operationelle for begge rammerOpretholde en ren og modulær arkitekturNedenfor er den endelige struktur efter at have gennemført migrationsworkflowet.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/ Bemærkninger om Strukturen.github/prompts/ — indeholder dine Copilot migrations-prompter. At holde disse versioner gør det muligt for dig at opdatere eller genbruge dem til fremtidige ramme-migreringer eller refactoringer..github/workflows/ — indeholder dine CI/CD-definitioner. Du kan køre både Playwright og Cypress-opgaver parallelt, indtil den gamle ramme er fuldstændigt udfaset.playwright/ mappen — fungerer nu som den primære automatiseringskilde fremadrettet. Det spejler strukturen fra den tidligere Cypress-implementering for at lette onboarding og sikre konsistens.tsconfig.playwright.json og tsconfig.cypress.json — forbliver adskilt for fuld type isolation, hvilket forhindrer konflikter under builds.Denne struktur støttede ikke kun en glat overgang, men positionerede også projektet til fremtidig skalerbarhed, CI-fleksibilitet og modulær testejerskab på tværs af teams.Praktiske Råd & Lærte LektionerEfter at have migreret næsten 150 tests med Copilot og Playwright, her er et par nøglelektioner og virkelige tips, der gjorde processen glattere (og sparede os for nogle hovedpine).Generel AI-Relateret RådAI lyver — ofte overbevisende. Bekræft altid hver linje kode, AI genererer. Stol aldrig blindt på det, især under infrastrukturmigreringer.Hold dig til konsistente navngivningskonventioner.Behold identiske variable og metode navne på tværs af rammer — det hjælper AI-agenten med at migrere kode mere præcist og gør det lettere for dig at finde og importere dem senere.Rebuild importer manuelt.Copilot har tendens til at rode importstierne. Det er ofte hurtigere at slette dem og importere dem manuelt, eller at opsætte globale imports som: import x from "playwright/foo/bar";

Genbrug den samme chat til alle migrationer. Hold dig til en enkelt Copilot chattråd — det opbygger kontekst og "husker" dine projektkonventioner, hvilket fører til bedre resultater.

Decomposer migrationsopgaver. Generer 1-2 filer ad gangen. Mindre opgaver giver mere præcise output og gør manuel validering lettere.

Playwright-Specifik Råd Opret aldrig flere instanser af den samme Page Object uden behov. At gøre dette kan forårsage inkonsistent tilstand eller brudte vælgere, når man navigerer mellem sider. Løsningen? Implementer en Page Manager, der holder alle sideobjekter tilgængelige gennem en enkelt instans.

Her er et minimalt eksempel på opsætning:

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("Brugeren skal logge ind med gyldige data", async ({ pageManager }) => { await pageManager.loginPage.clickLoginButton(); }); Andre Tekniske TipsFjern alle "get" præfikser fra lokatorer, som AI-agenten genererer — brug direkte lokator metoder i stedet.Glem ikke at konfigurere dotenv til miljøvariabler og legitimationsoplysninger.Tilpas din Playwright-konfiguration for at outputte alle rapporter under Playwright-mappen, så dit projektrod forbliver rent:ts reporter: [["html", { open: "never", outputFolder: "./playwright/reports/" }]], outputDir: "./playwright/test-results", EfterordJeg inkluderede ikke ESLint opsætning her, da det varierer fra projekt til projekt. Den eneste universelle anbefaling, jeg kan give, er at installere Playwright ESLint-pluginet for bedre regelhåndhævelse:eslint-plugin-playwrightHvis du ønsker at udforske et komplet fungerende eksempel på denne migration — herunder promptfiler, tsconfigs, og CI opsætning — kan du tjekke det fulde repository her:Repo eksempel