Testaus

Yleistä

Ylläpidettävien testien tekemiseen kannattaa suosia käytäntöjä, jotka eivät ota kantaa tarkkaan tekniseen toteutukseen, vaan jäljittelevät sitä miten asiakas palvelua käyttää.

• Tämä helpottaa versiopäivityksiä, kun komponenttien muutokset eivät aiheuta niin usein korjaustarpeita testeihin. Esimerkkinä Testing Libraryn ohjaavat periaatteet(Avautuu uuteen välilehteen).
• Jos roolin, saavutettavan nimen tai muun tekstin perusteella elementtiä on hankala etsiä, komponenteille saa asetettua testId-propin kautta data-testid-attribuutin.

Esimerkki testistä, joka testaa dialogia loppukäyttäjän näkökulmasta, eikä ole sidottu dialogin tekniseen toteutukseen:

it("should open the logout confirmation modal", async () => {
  render(<LogoutModal />);
  expect(screen.queryByRole("dialog")).not.toBeInTheDocument();

  await user.click(screen.getByText("Kirjaudu ulos"));
  expect(await screen.findByRole("dialog")).toBeInTheDocument();
  expect(within(screen.getByRole("dialog")).getByRole("button", { name: "Kirjaudu ulos" })).toHaveFocus();

  await user.click(within(screen.getByRole("dialog")).getByRole("button", { name: "Kirjaudu ulos" }));
  await waitFor(() => {
    expect(screen.queryByRole("dialog")).not.toBeInTheDocument();
  });
});

Huomioitavaa testauksessa

• Komponenttien automaattisesti generoidut id-attribuutit muodostetaan useId(Avautuu uuteen välilehteen)-hookilla, joten ne saattavat vaihtua.
• Snapshot-testauksessa kannattaa huomioida, että komponenttien HTML-rakenne voi muuttua versiopäivityksien yhteydessä.
• Testikirjastojen käyttämät virtuaali-DOM:t eivät tue kaikkia käytettyjä ominaisuuksia, joten ne vaativat mock-toteutuksen. Katso esimerkki käyttöönotto-ohjeesta.