Automatisering af frontend-test: Avancerede mønstre i Playwright og Cypress

I det konstant udviklende landskab for webudvikling er det altafgørende at sikre kvaliteten og pålideligheden af dine frontend-applikationer. Automatiseret test spiller en afgørende rolle i at nå dette mål. Playwright og Cypress er to populære JavaScript-baserede end-to-end (E2E) test-frameworks, der har vundet betydelig popularitet i de seneste år. Selvom begge tilbyder robuste muligheder for at oprette og køre tests, er det afgørende at mestre avancerede mønstre for at bygge vedligeholdelsesvenlige, skalerbare og pålidelige testsuiter. Denne omfattende guide dykker ned i disse avancerede mønstre og giver praktiske eksempler og indsigter til at løfte din frontend-teststrategi.

Forståelse af landskabet: Playwright vs. Cypress

Før vi dykker ned i avancerede mønstre, er det vigtigt at forstå de grundlæggende forskelle og styrker ved Playwright og Cypress. Begge frameworks sigter mod at forenkle E2E-test, men de griber problemet an med forskellige arkitekturer og designfilosofier.

Playwright: Kraftværket til cross-browser-test

Playwright, udviklet af Microsoft, skiller sig ud for sin cross-browser-kompatibilitet. Det understøtter Chromium, Firefox og WebKit (Safari), hvilket giver dig mulighed for at køre tests på alle større browsere med en enkelt kodebase. Playwright udmærker sig også ved at håndtere komplekse scenarier, der involverer flere faner, iframes og shadow DOM's. Dets auto-wait-mekanisme venter implicit på, at elementer bliver handlingsparate, hvilket reducerer ustabilitet i tests.

Cypress: Det udviklervenlige valg

Cypress, på den anden side, fokuserer på at levere en problemfri udvikleroplevelse. Dets 'time-travel debugging'-funktion, realtids-genindlæsninger og intuitive API gør det til en favorit blandt udviklere. Cypress kører direkte i browseren, hvilket giver enestående kontrol og synlighed i applikationens tilstand. Dog understøtter Cypress primært Chromium-baserede browsere og Firefox, med begrænset understøttelse af Safari.

Valget af det rigtige framework afhænger af dine specifikke behov og prioriteter. Hvis cross-browser-kompatibilitet er et must, er Playwright den klare vinder. Hvis udvikleroplevelse og debugging-muligheder er vigtigere, kan Cypress være et bedre valg.

Avancerede testmønstre: Et dybdegående kig

Lad os nu udforske nogle avancerede testmønstre, der markant kan forbedre kvaliteten og vedligeholdelsesvenligheden af dine Playwright- og Cypress-testsuiter.

1. Page Object Model (POM)

Page Object Model (POM) er et designmønster, der fremmer genbrugelighed og vedligeholdelsesvenlighed af kode ved at indkapsle elementerne og interaktionerne på en specifik side i en dedikeret klasse. Dette mønster hjælper med at abstrahere den underliggende HTML-struktur væk, hvilket gør dine tests mindre skrøbelige og lettere at opdatere, når brugergrænsefladen ændres.

Implementering (Playwright):

            // page.ts
import { expect, Locator, Page } from '@playwright/test';

export class HomePage {
    readonly page: Page;
    readonly searchInput: Locator;
    readonly searchButton: Locator;

    constructor(page: Page) {
        this.page = page;
        this.searchInput = page.locator('input[name="q"]');
        this.searchButton = page.locator('button[type="submit"]');
    }

    async goto() {
        await this.page.goto('https://www.example.com');
    }

    async search(searchTerm: string) {
        await this.searchInput.fill(searchTerm);
        await this.searchButton.click();
    }
}

            

              
                Copy
              
            
          

            // example.spec.ts
import { test, expect } from '@playwright/test';
import { HomePage } from './page';

test('search for a term', async ({ page }) => {
    const homePage = new HomePage(page);
    await homePage.goto();
    await homePage.search('Playwright');
    await expect(page).toHaveURL(/.*Playwright/);
});

            

              
                Copy
              
            
          

Implementering (Cypress):

            // page.js
class HomePage {
    visit() {
        cy.visit('https://www.example.com')
    }

    search(searchTerm) {
        cy.get('input[name="q"]')
            .type(searchTerm)
        cy.get('button[type="submit"]')
            .click()
    }

    verifySearch(searchTerm) {
        cy.url().should('include', searchTerm)
    }
}

export default HomePage

            

              
                Copy
              
            
          

            // example.spec.js
import HomePage from './page'

describe('Home Page', () => {
    it('should search for a term', () => {
        const homePage = new HomePage()
        homePage.visit()
        homePage.search('Cypress')
        homePage.verifySearch('Cypress')
    })
})

            

              
                Copy
              
            
          

2. Komponenttest

Komponenttest fokuserer på at teste individuelle UI-komponenter i isolation. Denne tilgang giver dig mulighed for at verificere funktionaliteten og adfærden for hver komponent uden at være afhængig af hele applikationen. Komponenttest er især nyttigt for komplekse UI-biblioteker og frameworks som React, Vue.js og Angular.

Fordele ved komponenttest:

• Hurtigere testudførelse: Komponenttests er typisk hurtigere end E2E-tests, fordi de kun tester en lille del af applikationen.
• Forbedret isolation: Komponenttests isolerer komponenter fra eksterne afhængigheder, hvilket gør det lettere at identificere og rette fejl.
• Bedre kodedækning: Komponenttest kan give bedre kodedækning ved at teste individuelle komponenter grundigt.

Implementering (Playwright med React):

Playwright kan bruges til komponenttest med værktøjer som Vite og React's Testing Library. Selvom Playwright udmærker sig ved E2E, kan specialiserede frameworks til komponenttest tilbyde en bedre udvikleroplevelse (DX) til dette specifikke formål.

Implementering (Cypress med React):

            // Button.jsx
import React from 'react';

function Button({ onClick, children }) {
  return {children};
}

export default Button;

            

              
                Copy
              
            
          

            // Button.cy.jsx
import React from 'react';
import Button from './Button';

describe('Button Component', () => {
  it('should call onClick when clicked', () => {
    const onClick = cy.stub();
    cy.mount(Click Me);
    cy.get('button').click();
    cy.wrap(onClick).should('be.called');
  });

  it('should display the children text', () => {
    cy.mount(Hello World);
    cy.get('button').should('contain', 'Hello World');
  });
});

            

              
                Copy
              
            
          

3. Visuel test

Visuel test indebærer sammenligning af skærmbilleder af din applikations brugergrænseflade med baseline-billeder for at opdage visuelle regressioner. Denne type test er essentiel for at sikre, at din applikation ser korrekt ud på tværs af forskellige browsere, enheder og skærmstørrelser. Visuel test kan fange subtile UI-problemer, som funktionelle tests måske overser.

Værktøjer til visuel test:

• Applitools: En kommerciel platform for visuel test, der tilbyder avanceret billedsammenligning og AI-drevet analyse.
• Percy: En anden populær kommerciel platform for visuel test, der integreres problemfrit med CI/CD-pipelines.
• Playwrights indbyggede snapshot-test: Playwright giver dig mulighed for at tage skærmbilleder og sammenligne dem med baselines direkte i dine tests.
• Cypress Image Snapshot: Et Cypress-plugin, der tilbyder lignende muligheder for skærmbilledsammenligning.

Implementering (Playwright med indbyggede snapshots):

            // visual.spec.ts
import { test, expect } from '@playwright/test';

test('homepage has correct visual appearance', async ({ page }) => {
  await page.goto('https://www.example.com');
  expect(await page.screenshot()).toMatchSnapshot('homepage.png');
});

            

              
                Copy
              
            
          

Implementering (Cypress med Cypress Image Snapshot):

            // cypress.config.js
const { defineConfig } = require('cypress')
const { initPlugin } = require('cypress-plugin-snapshots/plugin');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      initPlugin(on, config);
      return config;
    },
  },
})

            

              
                Copy
              
            
          

            // visual.spec.js
import { compareSnapshotCommand } from 'cypress-image-snapshot/command'
addMatchImageSnapshotCommand();

describe('Visual Regression Testing', () => {
    it('Homepage Visual Test', () => {
        cy.visit('https://www.example.com')
        cy.get('body').toMatchImageSnapshot()
    })
})

            

              
                Copy
              
            
          

4. Datadrevet test

Datadrevet test indebærer at køre den samme test med forskellige datasæt. Dette mønster er nyttigt til at verificere, at din applikation opfører sig korrekt med forskellige input og scenarier. Data kan hentes fra CSV-filer, JSON-filer, databaser eller endda eksterne API'er.

Fordele ved datadrevet test:

• Øget testdækning: Datadrevet test giver dig mulighed for at teste et bredere udvalg af scenarier med minimal kodeduplikering.
• Forbedret vedligeholdelsesvenlighed af tests: Datadrevne tests er lettere at opdatere og vedligeholde, fordi testlogikken er adskilt fra testdataene.
• Forbedret læsbarhed af tests: Datadrevne tests er ofte mere læsbare og forståelige, fordi testdataene er klart defineret.

Implementering (Playwright med JSON-data):

            // data.json
[
  {
    "username": "user1",
    "password": "pass1"
  },
  {
    "username": "user2",
    "password": "pass2"
  }
]

            

              
                Copy
              
            
          

            // data-driven.spec.ts
import { test, expect } from '@playwright/test';
import * as testData from './data.json';

testData.forEach((data) => {
  test(`login with ${data.username}`, async ({ page }) => {
    await page.goto('https://www.example.com/login'); // Erstat med din login-side
    await page.locator('#username').fill(data.username);
    await page.locator('#password').fill(data.password);
    await page.locator('button[type="submit"]').click();

    // Tilføj assertions for at verificere vellykket login
    // Eksempel: await expect(page).toHaveURL(/.*dashboard/);
  });
});

            

              
                Copy
              
            
          

Implementering (Cypress med fixture-data):

            // cypress/fixtures/data.json
[
  {
    "username": "user1",
    "password": "pass1"
  },
  {
    "username": "user2",
    "password": "pass2"
  }
]

            

              
                Copy
              
            
          

            // data-driven.spec.js
describe('Data-Driven Testing', () => {
  it('Login with multiple users', () => {
    cy.fixture('data.json').then((users) => {
      users.forEach((user) => {
        cy.visit('https://www.example.com/login') // Erstat med din login-side
        cy.get('#username').type(user.username)
        cy.get('#password').type(user.password)
        cy.get('button[type="submit"]').click()

        // Tilføj assertions for at verificere vellykket login
        // Eksempel: cy.url().should('include', '/dashboard')
      })
    })
  })
})

            

              
                Copy
              
            
          

5. API-test inden for E2E-tests

At integrere API-test i dine E2E-tests kan give en mere omfattende og pålidelig teststrategi. Denne tilgang giver dig mulighed for at verificere backend-funktionaliteten, der driver din frontend-applikation, og sikrer, at data flyder korrekt, og at brugergrænsefladen afspejler den forventede tilstand.

Fordele ved API-test inden for E2E-tests:

• Tidlig opdagelse af backend-problemer: API-tests kan identificere backend-problemer tidligt i udviklingscyklussen og forhindre dem i at påvirke frontenden.
• Forbedret testpålidelighed: API-tests kan sikre, at backenden er i en kendt tilstand, før frontend-tests køres, hvilket reducerer ustabilitet.
• End-to-end-validering: Kombinationen af API- og UI-tests giver en komplet end-to-end-validering af din applikations funktionalitet.

Implementering (Playwright):

            // api.spec.ts
import { test, expect } from '@playwright/test';

test('create a new user via API and verify in UI', async ({ page, request }) => {
  // 1. Opret en bruger via API
  const response = await request.post('/api/users', {
    data: {
      name: 'John Doe',
      email: 'john.doe@example.com'
    }
  });
  expect(response.status()).toBe(201); // Antager 201 Created
  const responseBody = await response.json();
  const userId = responseBody.id;

  // 2. Naviger til brugerlisten i UI'en
  await page.goto('/users'); // Erstat med din brugerlisteside

  // 3. Verificer, at den nye bruger vises
  await expect(page.locator(`text=${'John Doe'}`)).toBeVisible();
});

            

              
                Copy
              
            
          

Implementering (Cypress):

            // api.spec.js
describe('API and UI Integration Test', () => {
  it('Creates a user via API and verifies it in the UI', () => {
    // 1. Opret en bruger via API
    cy.request({
      method: 'POST',
      url: '/api/users', // Erstat med dit API-endepunkt
      body: {
        name: 'Jane Doe',
        email: 'jane.doe@example.com'
      }
    }).then((response) => {
      expect(response.status).to.eq(201) // Antager 201 Created
      const userId = response.body.id

      // 2. Naviger til brugerlisten i UI'en
      cy.visit('/users') // Erstat med din brugerlisteside

      // 3. Verificer, at den nye bruger vises
      cy.contains('Jane Doe').should('be.visible')
    })
  })
})

            

              
                Copy
              
            
          

6. Tilgængelighedstest

Tilgængelighedstest sikrer, at din applikation kan bruges af personer med handicap. Denne type test er afgørende for at skabe inkluderende og lige weboplevelser. Automatiseret tilgængelighedstest kan hjælpe dig med at identificere almindelige tilgængelighedsproblemer, såsom manglende alt-tekst, utilstrækkelig farvekontrast og problemer med tastaturnavigation.

Værktøjer til tilgængelighedstest:

• axe-core: Et populært open-source-bibliotek til tilgængelighedstest.
• axe DevTools: En browserudvidelse, der giver realtids-feedback om tilgængelighed.
• Lighthouse: Et værktøj til webperformance og revision, der inkluderer tilgængelighedstjek.

Implementering (Playwright med axe-core):

            // accessibility.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage should pass accessibility checks', async ({ page }) => {
  await page.goto('https://www.example.com');
  const axeBuilder = new AxeBuilder({ page });
  const accessibilityScanResults = await axeBuilder.analyze();
  expect(accessibilityScanResults.violations).toEqual([]); // Eller håndter overtrædelser passende
});

            

              
                Copy
              
            
          

Implementering (Cypress med axe-core):

            // support/commands.js
import 'cypress-axe'

Cypress.Commands.add('checkA11y', (context, options) => {
  cy.configureAxe(options)
  cy.checkA11y(context, options)
})

            

              
                Copy
              
            
          

            // accessibility.spec.js
describe('Accessibility Testing', () => {
  it('Homepage should be accessible', () => {
    cy.visit('https://www.example.com')
    cy.injectAxe()
    cy.checkA11y()
  })
})

            

              
                Copy
              
            
          

7. Håndtering af autentificering og autorisation

Autentificering og autorisation er kritiske aspekter af webapplikationssikkerhed. At teste disse funktioner grundigt er essentielt for at beskytte brugerdata og forhindre uautoriseret adgang.

Strategier for test af autentificering og autorisation:

• UI-baseret autentificering: Simuler brugerlogin gennem brugergrænsefladen og verificer, at applikationen korrekt autentificerer og autoriserer brugeren.
• API-baseret autentificering: Brug API-kald til at opnå autentificeringstokens og brug derefter disse tokens til at få adgang til beskyttede ressourcer.
• Test af rollebaseret adgangskontrol (RBAC): Verificer, at brugere med forskellige roller har de passende tilladelser til at få adgang til forskellige dele af applikationen.

Eksempel (Playwright - UI-baseret autentificering):

            // auth.spec.ts
import { test, expect } from '@playwright/test';

test('login and access protected resource', async ({ page }) => {
  await page.goto('/login'); // Erstat med din login-side
  await page.locator('#username').fill('valid_user');
  await page.locator('#password').fill('valid_password');
  await page.locator('button[type="submit"]').click();
  await expect(page).toHaveURL(/.*dashboard/); // Erstat med din dashboard-URL

  // Få nu adgang til en beskyttet ressource
  await page.goto('/protected-resource'); // Erstat med din URL til beskyttet ressource
  await expect(page.locator('h1')).toContainText('Protected Resource');
});

            

              
                Copy
              
            
          

Eksempel (Cypress - API-baseret autentificering):

            // auth.spec.js
describe('Authentication Testing', () => {
  it('Logs in via API and accesses a protected resource', () => {
    // 1. Få et autentificeringstoken fra API'et
    cy.request({
      method: 'POST',
      url: '/api/login', // Erstat med dit login API-endepunkt
      body: {
        username: 'valid_user',
        password: 'valid_password'
      }
    }).then((response) => {
      expect(response.status).to.eq(200)
      const token = response.body.token

      // 2. Sæt token'et i local storage eller cookies
      cy.setLocalStorage('authToken', token)

      // 3. Besøg den beskyttede ressource, som nu er autentificeret
      cy.visit('/protected-resource') // Erstat med din URL til beskyttet ressource

      // 4. Verificer, at brugeren kan få adgang til ressourcen
      cy.contains('Protected Content').should('be.visible')
    })
  })
})

            

              
                Copy
              
            
          

Bedste praksis for vedligeholdelse af testsuiter

At bygge en robust og pålidelig testsuite er kun halvdelen af kampen. At vedligeholde den over tid er lige så vigtigt. Her er nogle bedste praksisser for at holde dine Playwright- og Cypress-testsuiter i god stand.

1. Hold tests fokuserede og præcise

Hver test bør fokusere på at verificere en enkelt, specifik del af funktionaliteten. Undgå at skabe alt for komplekse tests, der forsøger at dække for meget. Præcise tests er lettere at forstå, debugge og vedligeholde.

2. Brug meningsfulde testnavne

Giv dine tests klare og beskrivende navne, der præcist afspejler, hvad de tester. Dette vil gøre det lettere at forstå formålet med hver test og hurtigt identificere fejl.

3. Undgå at hardcode værdier

Undgå at hardcode værdier direkte i dine tests. Brug i stedet konfigurationsfiler eller miljøvariabler til at gemme testdata. Dette vil gøre det lettere at opdatere dine tests, når applikationen ændres.

4. Gennemgå og refaktorér tests regelmæssigt

Planlæg regelmæssige gennemgange af din testsuite for at identificere og refaktorere tests, der bliver skrøbelige eller svære at vedligeholde. Fjern tests, der ikke længere er relevante, eller som giver begrænset værdi.

5. Integrer med CI/CD-pipelines

Integrer dine Playwright- og Cypress-tests i dine CI/CD-pipelines for at sikre, at tests køres automatisk, hver gang koden ændres. Dette vil hjælpe dig med at fange fejl tidligt og forhindre, at regressioner når ud i produktionen.

6. Brug værktøjer til testrapportering og -analyse

Benyt værktøjer til testrapportering og -analyse til at spore testresultater, identificere tendenser og udpege områder til forbedring. Disse værktøjer kan give værdifuld indsigt i din applikations sundhed og stabilitet.

Konklusion

At mestre avancerede testmønstre med Playwright og Cypress er essentielt for at bygge robuste, vedligeholdelsesvenlige og skalerbare frontend-applikationer. Ved at implementere de mønstre og bedste praksisser, der er beskrevet i denne guide, kan du markant forbedre kvaliteten og pålideligheden af dine testsuiter og levere enestående brugeroplevelser. Tag disse teknikker til dig, og du vil være godt rustet til at tackle udfordringerne ved moderne frontend-test. Husk at tilpasse disse mønstre til dine specifikke projektkrav og konstant stræbe efter at forbedre din teststrategi. God fornøjelse med testningen!