Hoppa till huvudinnehåll

Tester

Automatiska tester i Midas utgörs främst av komponenttester. Komponenttester testar interaktionen av renderade komponenter i en riktig eller emulerad webbläsare. I de riktiga webbläsarna utförs automatiserade tillgänglighetstester och på sikt även visuella tester.

Vi har också möjlighet att skriva enhetstester som testar delar ur JavaScript-moduler.

Webbläsartester​

Midas använder Storybook som primär testplattform, med Storybooks playfunktion får vi tillgång till ett flertal riktiga webbläsare som kan köra våra tester lokalt och i våra CI/CD pipelines. Skriv ditt test här i första hand, det hjälper oss att säkerställa att vi har stories för en komponents samtliga tillstånd.

Kör webbläsartester​

Tester som använder Storybooks play-funktion kan köras via terminalen med hjälp av Storybook test runner. Under huven används Jest, Playwright och Testing library.

Se till att ha din lokala Storybook igång innan du kör några tester:

nx run components:storybook

Kör tester i light mode​

Per default använder webbläsaren ljust läge för komponenterna.

nx run components:test-storybook

Kör tester i dark mode​

Vi behöver testa att våra komponenter uppfyller tillgänglighetskrav i mörkt läge, vi testar detta med följande kommando:

nx run components:test-storybook:dark-mode

Kör tester kontinuerligt​

Oavsett val av färgtema kan du låta ett testkommando vänta på att du sparar ändringar i en fil, för att sedan köra berörda tester igen:

nx run components:test-storybook --watch

Skriva webbläsartester​

Mycket kan testas på våra komponenter, och mycket kanske redan testas av de bibliotek vi utgår ifrån. Försök skriva ett test som kompletterar redan skrivna tester, kom ihåg att ditt test kommer behöva underhållas i framtiden.

Interaktioner och förväntade tillstånd​

Erbjuder din komponent interaktion kan du skriva tester där en simulerad användare använder musen eller tangentbordet för att framkalla ett visst tillstånd. Använd userEvent från @storybook/test när du simulerar din användare.

Tillgänglighetstester​

Med @storybook/addon-a11y utförs tillgänglighetstester med axe på varje komponent, dessa testas även av Storybook test runner i samtliga play tester, se packages/components/.storybook/test-runner.ts.

Automatiserade tillgänglighetstester fångar upp en stor del av brister gentemot WCAG-standarden men kan självklart kompletteras.

Med hjälp av tangentbords-interaktion i dina interaktionstester testar du att din komponent kan användas med enbart tangentbordet. Du kan också välja att använda queries för att säkerställa att du använder DOM-element som säger något åt en skärmläsare, getByRole, getByLabelText osv.

Buggrättning med TDD​

Om du rättar en bugg erbjuds du ett unikt tillfälle att skriva ett test som återskapar din bug, förhoppningsvis kommer vi då inte att återinföra buggen.

Börja med att sätta upp berörd komponent i en separat story, skriv sedan ett test som återskapar din bug, ditt mål är att få ett test som "failar".

// Ett bra tillfälle att notera ärendenumret som beskriver felet
export const DS123: Story = {
  // Dölj gärna storyn från Storybooks UI om den inte ger något direkt värde åt andra intressenter
  tags: ['!dev', '!autodocs'],
  args: {
    label: 'Select a value',
    options: [{ id: 'banana', name: 'Banana' }],
  },
  play: async ({ args, step, canvas }) => {
    // Använd gärna den inbyggda step-funktionen för att beskriva vad ditt test gör
    await step('It should be possible to select a value with the keyboard', async () => {
      // Interagera med userEvent
      await userEvent.tab()
      await userEvent.keyboard('[Space]')
      await userEvent.keyboard('[Space]')
      // Skriv minst en förväntning med expect
      expect(canvas.getByLabelText(args.label as string)).toHaveDisplayValue('banana')
    })
  },
}

Nu kan du åtgärda din bug, när du är klar bör ditt test passera.

Visuella tester​

För närvarande utför vi inga visuella tester där screenshots används för att jämföra komponenters utseende.

toHaveStyle​

expect från @storybook/test erbjuder dig att skriva förväntningar på hur en komponent ser ut med hjälp av toHaveStyle-metoden. Då metoden inte är helt pålitlig bör den användas som en sista utväg tillsammans med lightDark-utility från packages/components/src/utils/test.ts.

Enhetstester​

Behöver du skriva enhetstester av rena JavaScript-moduler eller använda en emulerad webbläsare (jsdom) för att testa dina komponenter kan du använda filnamn enligt mönstret **/?(*.)+(spec|test).[jt]s?(x). Exempelvis: packages/components/src/badge/badge.spec.ts.

Enhetstesterna körs också av Jest och accepterar samma argument som när webbläsartesterna körs.

Kör enhetstester​

nx test components

Kör enhetstester kontinuerligt när du sparar en fil​

nx test components --watch

Skriva enhetstester​

I våra .spec|.test-filer är Jest definerat globalt, det krävs därför inga importer av describe, beforeEach, test/it, expect, etc.

Om du har en separerad kod kan du importera delar av en JavaScript-modul och kontrollera att den fungerar som du vill med hjälp av ett test. Gör något i stil med:

sum.spec.ts
import sum from './sum'

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3)
})

Emulerad webbläsare​

Om du av någon anledning behöver skriva ett komponenttest med en emulerad webbläsare behöver du använda screen och expect från @testing-library/react. Hämta även en uppsatt simulerad användare från packages/components/tests/utils/user om du behöver interagera med din komponent.

Sätt gärna upp en komponent i beforeEach-hooken så att det är lätt att skriva flera tester på samma tillstånd.

Button.spec.tsx
import { render, screen } from '@testing-library/react'
import { Button } from './Button'
import user from 'tests/utils/user'

describe('given a default Button', () => {
  const label = 'my button'
  const handleClick = jest.fn()

  beforeEach(() => {
    render(<Button onPress={handleClick}>{label}</Button>)
  })

  it('should be clickable and visible', async () => {
    const button = screen.getByRole('button', { name: label })
    await user.click(button)
    expect(handleClick).toHaveBeenCalledTimes(1)
    expect(button).toBeVisible()
  })
})