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, snapshottester körs i Chromatic.

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 Vitest addon. Under huven används Vitest, Playwright och Testing library.

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

nx serve storybook

Kör tester i light mode

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

nx 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 storybook:test: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 storybook:test: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 i våra workfows med kommandot nx test storybook.

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.

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.

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()
  })
})

Snapshottester

Vi använder Chromatic för att köra snapshottester som jämför visuella ändringar i komponenter. Chromatic utgår från vår Storybook och tar snapshots på samtliga stories.

Trigga snapshottester

Snapshottester körs automatiskt vid push till följande brancher:

• main
• brancher som startar med feature
• brancher som startar med feat
• brancher som startar med fix
• brancher som startar med bugfix

Hoppa över stories

För att reducera antalet snapshots bör vi bara ta en snap per tillstånd i en komponent, vänligen använd följande kod om du vill att chromatic ska hoppa över din story:

export const PrimaryWithAnotherLabel: Story = {
  args: {
    label: 'Just another label',
  },
  parameters: {
    chromatic: {
      disableSnapshot: true,
    },
  },
  // ...
}