React Testing Library: Komponentide testimise parimad praktikad globaalsetele meeskondadele

Pidevalt arenevas veebiarenduse maailmas on teie Reacti rakenduste usaldusväärsuse ja kvaliteedi tagamine esmatähtis. See kehtib eriti globaalsete meeskondade kohta, kes töötavad projektide kallal, millel on mitmekesine kasutajaskond ja ligipääsetavusnõuded. React Testing Library (RTL) pakub võimsat ja kasutajakeskset lähenemist komponentide testimisele. Erinevalt traditsioonilistest testimismeetoditest, mis keskenduvad implementatsiooni detailidele, julgustab RTL teid testima oma komponente nii, nagu kasutaja nendega suhtleks, mis viib vastupidavamate ja hooldatavamate testideni. See põhjalik juhend süveneb RTL-i kasutamise parimatesse praktikatesse teie Reacti projektides, keskendudes rakenduste ehitamisele, mis sobivad globaalsele publikule.

Miks React Testing Library?

Enne parimatesse praktikatesse sukeldumist on oluline mõista, miks RTL teistest testimisraamistikkudest eristub. Siin on mõned peamised eelised:

• Kasutajakeskne lähenemine: RTL seab esikohale komponentide testimise kasutaja vaatenurgast. Te suhtlete komponendiga samade meetoditega, mida kasutaja kasutaks (nt nuppudele klõpsamine, sisestusväljadele trükkimine), tagades realistlikuma ja usaldusväärsema testimiskogemuse.
• Ligipääsetavusele keskendunud: RTL edendab ligipääsetavate komponentide kirjutamist, julgustades teid testima neid viisil, mis arvestab puuetega kasutajaid. See on kooskõlas globaalsete ligipääsetavusstandarditega nagu WCAG.
• Vähenenud hooldusvajadus: Vältides implementatsiooni detailide (nt sisemine olek, konkreetsed funktsioonikutsed) testimist, on RTL-i testidel väiksem tõenäosus puruneda, kui te oma koodi refaktoorite. See viib hooldatavamate ja vastupidavamate testideni.
• Parem koodidisain: RTL-i kasutajakeskne lähenemine viib sageli parema komponentide disainini, kuna olete sunnitud mõtlema sellele, kuidas kasutajad teie komponentidega suhtlevad.
• Kogukond ja ökosüsteem: RTL-il on suur ja aktiivne kogukond, mis pakub rohkelt ressursse, tuge ja laiendusi.

Testimiskeskkonna seadistamine

RTL-iga alustamiseks peate seadistama oma testimiskeskkonna. Siin on põhiseadistus, kasutades Create React Appi (CRA), mis on eelkonfigureeritud Jesti ja RTL-iga:

npx create-react-app my-react-app
cd my-react-app
npm install --save-dev @testing-library/react @testing-library/jest-dom

Selgitus:

• `npx create-react-app my-react-app`: Loob uue Reacti projekti, kasutades Create React Appi.
• `cd my-react-app`: Liigub äsja loodud projekti kausta.
• `npm install --save-dev @testing-library/react @testing-library/jest-dom`: Installib vajalikud RTL-i paketid arendussõltuvustena. `@testing-library/react` pakub RTL-i põhilist funktsionaalsust, samas kui `@testing-library/jest-dom` pakub kasulikke Jesti võrdlejaid DOM-iga töötamiseks.

Kui te ei kasuta CRA-d, peate installima Jesti ja RTL-i eraldi ning konfigureerima Jesti RTL-i kasutama.

Komponentide testimise parimad praktikad React Testing Library'ga

1. Kirjutage teste, mis sarnanevad kasutaja interaktsioonidega

RTL-i põhiprintsiip on testida komponente nii, nagu kasutaja seda teeks. See tähendab keskendumist sellele, mida kasutaja näeb ja teeb, mitte sisemistele implementatsiooni detailidele. Kasutage RTL-i pakutavat `screen` objekti, et leida elemente nende teksti, rolli või ligipääsetavuse siltide alusel.

Näide: Nupuvajutuse testimine

Oletame, et teil on lihtne nupu komponent:

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

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

export default Button;

Siin on, kuidas te seda RTL-i abil testiksite:

// Button.test.js
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Button from './Button';

describe('Button Component', () => {
  it('calls the onClick handler when clicked', () => {
    const handleClick = jest.fn();
    render(Click Me);

    const buttonElement = screen.getByText('Click Me');
    fireEvent.click(buttonElement);

    expect(handleClick).toHaveBeenCalledTimes(1);
  });
});

Selgitus:

• `render(Click Me)`: Renderdab nupu komponendi koos näiva `onClick` käsitlejaga.
• `screen.getByText('Click Me')`: Teeb päringu dokumendist elemendi leidmiseks, mis sisaldab teksti "Click Me". Nii tuvastaks kasutaja nupu.
• `fireEvent.click(buttonElement)`: Simuleerib nupu elemendil klõpsamissündmust.
• `expect(handleClick).toHaveBeenCalledTimes(1)`: Kinnitab, et `onClick` käsitlejat kutsuti välja üks kord.

Miks see on parem kui implementatsiooni detailide testimine: Kujutage ette, et te refaktoorite nupu komponenti, et kasutada teist sündmusekäsitlejat või muuta sisemist olekut. Kui testiksite konkreetset sündmusekäsitleja funktsiooni, läheks teie test katki. Keskendudes kasutaja interaktsioonile (nupule klõpsamine), jääb test kehtima ka pärast refaktoorimist.

2. Eelistage päringuid kasutaja kavatsuse alusel

RTL pakub elementide leidmiseks erinevaid päringumeetodeid. Eelistage järgmisi päringuid selles järjekorras, kuna need peegeldavad kõige paremini, kuidas kasutajad teie komponente tajuvad ja nendega suhtlevad:

• getByRole: See päring on kõige ligipääsetavam ja peaks olema teie esimene valik. See võimaldab leida elemente nende ARIA rollide alusel (nt nupp, link, pealkiri).
• getByLabelText: Kasutage seda, et leida elemente, mis on seotud konkreetse sildiga, näiteks sisestusväljad.
• getByPlaceholderText: Kasutage seda, et leida sisestusvälju nende kohatäiteteksti alusel.
• getByText: Kasutage seda, et leida elemente nende tekstilise sisu alusel. Olge konkreetne ja vältige üldise teksti kasutamist, mis võib esineda mitmes kohas.
• getByDisplayValue: Kasutage seda, et leida sisestusvälju nende hetkeväärtuse alusel.

Näide: Vormi sisendi testimine

// Input.js
import React from 'react';

function Input({ label, placeholder, value, onChange }) {
  return (
    

      {label}
      
    
  );
}

export default Input;

Siin on, kuidas seda testida, kasutades soovitatud päringute järjekorda:

// Input.test.js
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Input from './Input';

describe('Input Component', () => {
  it('updates the value when the user types', () => {
    const handleChange = jest.fn();
    render();

    const inputElement = screen.getByLabelText('Name');
    fireEvent.change(inputElement, { target: { value: 'John Doe' } });

    expect(handleChange).toHaveBeenCalledTimes(1);
    expect(handleChange).toHaveBeenCalledWith(expect.objectContaining({ target: { value: 'John Doe' } }));
  });
});

Selgitus:

• `screen.getByLabelText('Name')`: Kasutab `getByLabelText`, et leida sisestusväli, mis on seotud sildiga "Name". See on kõige ligipääsetavam ja kasutajasõbralikum viis sisendi leidmiseks.

3. Vältige implementatsiooni detailide testimist

Nagu varem mainitud, vältige sisemise oleku, funktsioonikutsete või konkreetsete CSS-klasside testimist. Need on implementatsiooni detailid, mis võivad muutuda ja põhjustada hapraid teste. Keskenduge komponendi vaadeldavale käitumisele.

Näide: Vältige oleku otsetestimist

Selle asemel, et testida, kas konkreetne olekumuutuja on uuendatud, testige, kas komponent renderdab selle oleku põhjal õige väljundi. Näiteks, kui komponent kuvab teate tõeväärtusmuutuja alusel, testige, kas teade on kuvatud või peidetud, mitte ärge testige olekumuutujat ennast.

4. Kasutage `data-testid` atribuuti erijuhtudel

Kuigi üldiselt on parem vältida `data-testid` atribuutide kasutamist, on erijuhte, kus need võivad olla abiks:

• Semantilise tähenduseta elemendid: Kui peate sihtima elementi, millel pole tähenduslikku rolli, silti ega teksti, võite kasutada `data-testid`.
• Keerulised komponendistruktuurid: Keerulistes komponendistruktuurides aitab `data-testid` sihtida konkreetseid elemente, ilma et peaksite toetuma habrastele selektoritele.
• Ligipääsetavuse testimine: `data-testid` saab kasutada konkreetsete elementide tuvastamiseks ligipääsetavuse testimisel tööriistadega nagu Cypress või Playwright.

Näide: `data-testid` kasutamine

// MyComponent.js
import React from 'react';

function MyComponent() {
  return (
    

      
This is my component.
    
  );
}

export default MyComponent;

// MyComponent.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('renders the component container', () => {
    render();
    const containerElement = screen.getByTestId('my-component-container');
    expect(containerElement).toBeInTheDocument();
  });
});

Oluline: Kasutage `data-testid` säästlikult ja ainult siis, kui teised päringumeetodid ei sobi.

5. Kirjutage tähendusrikkaid testikirjeldusi

Selged ja lühikesed testikirjeldused on iga testi eesmärgi mõistmiseks ja vigade silumiseks üliolulised. Kasutage kirjeldavaid nimesid, mis selgitavad selgelt, mida test kontrollib.

Näide: Head vs. halvad testikirjeldused

Halb: `it('töötab')`

Hea: `it('kuvab õige tervitussõnumi')`

Veel parem: `it('kuvab tervitussõnumi "Hello, World!", kui nime prop-i pole antud')`

Parem näide kirjeldab selgelt komponendi oodatavat käitumist konkreetsetes tingimustes.

6. Hoidke oma testid väikesed ja fokusseeritud

Iga test peaks keskenduma komponendi käitumise ühe aspekti kontrollimisele. Vältige suurte, keeruliste testide kirjutamist, mis katavad mitu stsenaariumi. Väikesi, fokusseeritud teste on lihtsam mõista, hooldada ja siluda.

7. Kasutage test-asendajaid (mock'id ja spioonid) asjakohaselt

Test-asendajad on kasulikud testitava komponendi eraldamiseks selle sõltuvustest. Kasutage mock'e ja spioone väliste teenuste, API-kutsete või teiste komponentide simuleerimiseks.

Näide: API-kutse mock'imine

// UserList.js
import React, { useState, useEffect } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    async function fetchUsers() {
      const response = await fetch('/api/users');
      const data = await response.json();
      setUsers(data);
    }

    fetchUsers();
  }, []);

  return (
    

      {users.map(user => (
        
{user.name}
      ))}
    
  );
}

export default UserList;

// UserList.test.js
import React from 'react';
import { render, screen, waitFor } from '@testing-library/react';
import UserList from './UserList';

global.fetch = jest.fn(() =>
  Promise.resolve({
    json: () => Promise.resolve([
      { id: 1, name: 'John Doe' },
      { id: 2, name: 'Jane Smith' },
    ]),
  })
);

describe('UserList Component', () => {
  it('fetches and displays a list of users', async () => {
    render();

    // Wait for the data to load
    await waitFor(() => screen.getByText('John Doe'));

    expect(screen.getByText('John Doe')).toBeInTheDocument();
    expect(screen.getByText('Jane Smith')).toBeInTheDocument();
  });
});

Selgitus:

• `global.fetch = jest.fn(...)`: Mock'ib `fetch`-funktsiooni, et tagastada eelmääratletud kasutajate loend. See võimaldab teil testida komponenti ilma reaalsele API lõpp-punktile tuginemata.
• `await waitFor(() => screen.getByText('John Doe'))`: Ootab, kuni tekst "John Doe" ilmub dokumenti. See on vajalik, kuna andmeid laaditakse asünkroonselt.

8. Testige äärmusjuhtumeid ja veakäsitlust

Ärge testige ainult õnnelikku stsenaariumi. Testige kindlasti ka äärmusjuhtumeid, veaolukordi ja piirtingimusi. See aitab teil potentsiaalseid probleeme varakult tuvastada ja tagada, et teie komponent käsitleb ootamatuid olukordi sujuvalt.

Näide: Veakäsitluse testimine

Kujutage ette komponenti, mis laadib andmeid API-st ja kuvab veateate, kui API-kutse ebaõnnestub. Peaksite kirjutama testi, et kontrollida, kas veateade kuvatakse õigesti, kui API-kutse ebaõnnestub.

9. Keskenduge ligipääsetavusele

Ligipääsetavus on kaasavate veebirakenduste loomisel ülioluline. Kasutage RTL-i oma komponentide ligipääsetavuse testimiseks ja veendumaks, et need vastavad ligipääsetavusstandarditele nagu WCAG. Mõned olulised ligipääsetavuse kaalutlused on järgmised:

• Semantiline HTML: Kasutage semantilisi HTML-elemente (nt ``, `
• ARIA atribuudid: Kasutage ARIA atribuute, et anda lisateavet elementide rolli, oleku ja omaduste kohta, eriti kohandatud komponentide puhul.
• Klaviatuurinavigatsioon: Veenduge, et kõik interaktiivsed elemendid oleksid klaviatuuriga navigeeritavad.
• Värvikontrastsus: Kasutage piisavat värvikontrastsust, et tekst oleks vaegnägijatele loetav.
• Ekraanilugeja ühilduvus: Testige oma komponente ekraanilugejaga, et tagada, et need pakuvad nägemispuudega kasutajatele tähenduslikku ja arusaadavat kogemust.

Näide: Ligipääsetavuse testimine `getByRole` abil

// MyAccessibleComponent.js
import React from 'react';

function MyAccessibleComponent() {
  return (
    X
  );
}

export default MyAccessibleComponent;

// MyAccessibleComponent.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import MyAccessibleComponent from './MyAccessibleComponent';

describe('MyAccessibleComponent', () => {
  it('renders an accessible button with the correct aria-label', () => {
    render();
    const buttonElement = screen.getByRole('button', { name: 'Close' });
    expect(buttonElement).toBeInTheDocument();
  });
});

Selgitus:

• `screen.getByRole('button', { name: 'Close' })`: Kasutab `getByRole`, et leida nupu element ligipääsetava nimega "Close". See tagab, et nupp on ekraanilugejate jaoks õigesti sildistatud.

10. Integreerige testimine oma arendustöövoogu

Testimine peaks olema teie arendustöövoo lahutamatu osa, mitte tagantjärele tarkus. Integreerige oma testid oma CI/CD konveieri, et testid käivituksid automaatselt iga kord, kui koodi lisatakse või paigaldatakse. See aitab teil vigu varakult tabada ja vältida regressioone.

11. Arvestage lokaliseerimise ja rahvusvahelistamisega (i18n)

Globaalsete rakenduste puhul on testimisel ülioluline arvestada lokaliseerimise ja rahvusvahelistamisega (i18n). Veenduge, et teie komponendid renderduksid korrektselt erinevates keeltes ja lokaatides.

Näide: Lokaliseerimise testimine

Kui kasutate lokaliseerimiseks raamistikkku nagu `react-intl` või `i18next`, saate oma testides mock'ida lokaliseerimiskonteksti, et kontrollida, kas teie komponendid kuvavad õiget tõlgitud teksti.

12. Kasutage korduvkasutatava seadistuse jaoks kohandatud renderdamisfunktsioone

Suuremate projektide kallal töötades võite avastada, et kordate samu seadistussamme mitmes testis. Dubleerimise vältimiseks looge kohandatud renderdamisfunktsioone, mis kapseldavad ühise seadistusloogika.

Näide: Kohandatud renderdamisfunktsioon

// test-utils.js
import React from 'react';
import { render } from '@testing-library/react';
import { ThemeProvider } from 'styled-components';
import theme from './theme';

const AllTheProviders = ({ children }) => {
  return (
    
      {children}
    
  );
}

const customRender = (ui, options) =>
  render(ui, { wrapper: AllTheProviders, ...options })

// re-export everything
export * from '@testing-library/react'

// override render method
export { customRender as render }

// MyComponent.test.js
import React from 'react';
import { render, screen } from './test-utils'; // Import the custom render
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('renders correctly with the theme', () => {
    render();
    // Your test logic here
  });
});

See näide loob kohandatud renderdamisfunktsiooni, mis mähkib komponendi ThemeProvideriga. See võimaldab teil hõlpsasti testida komponente, mis sõltuvad teemast, ilma et peaksite ThemeProvideri seadistust igas testis kordama.

Kokkuvõte

React Testing Library pakub võimast ja kasutajakeskset lähenemist komponentide testimisele. Neid parimaid praktikaid järgides saate kirjutada hooldatavaid ja tõhusaid teste, mis keskenduvad kasutajakäitumisele ja ligipääsetavusele. See viib vastupidavamate, usaldusväärsemate ja kaasavamate Reacti rakendusteni globaalsele publikule. Pidage meeles, et peate eelistama kasutaja interaktsioone, vältima implementatsiooni detailide testimist, keskenduma ligipääsetavusele ja integreerima testimise oma arendustöövoogu. Neid põhimõtteid omaks võttes saate luua kvaliteetseid Reacti rakendusi, mis vastavad kasutajate vajadustele üle kogu maailma.

Põhilised järeldused:

• Keskenduge kasutaja interaktsioonidele: Testige komponente nii, nagu kasutaja nendega suhtleks.
• Eelistage ligipääsetavust: Veenduge, et teie komponendid on puuetega kasutajatele ligipääsetavad.
• Vältige implementatsiooni detaile: Ärge testige sisemist olekut ega funktsioonikutseid.
• Kirjutage selgeid ja lühikesi teste: Tehke oma testid kergesti mõistetavaks ja hooldatavaks.
• Integreerige testimine oma töövoogu: Automatiseerige oma testid ja käivitage neid regulaarselt.
• Arvestage globaalse publikuga: Veenduge, et teie komponendid töötavad hästi erinevates keeltes ja lokaatides.