Reacti komponentide testimine: põhjalik juhend isoleeritud ühiktestimiseks

Kaasaegses veebiarenduse maailmas on robustsete ja hooldatavate rakenduste loomine esmatähtis. React, juhtiv JavaScripti teek kasutajaliideste ehitamiseks, võimaldab arendajatel luua dünaamilisi ja interaktiivseid veebikogemusi. Reacti rakenduste keerukus nõuab aga põhjalikku testimisstrateegiat, et tagada koodi kvaliteet ja vältida regressioone. See juhend keskendub Reacti testimise ühele olulisele aspektile: isoleeritud ühiktestimisele.

Mis on isoleeritud ühiktestimine?

Isoleeritud ühiktestimine on tarkvara testimise tehnika, kus rakenduse üksikuid ühikuid või komponente testitakse süsteemi teistest osadest eraldi. Reacti kontekstis tähendab see üksikute Reacti komponentide testimist, ilma et sõltutaks nende sõltuvustest, nagu alamkomponendid, välised API-d või Reduxi poest. Peamine eesmärk on kontrollida, et iga komponent toimib korrektselt ja annab kindlate sisendite korral oodatud väljundi, ilma väliste tegurite mõjuta.

Miks on isoleerimine oluline?

Komponentide isoleerimine testimise ajal pakub mitmeid olulisi eeliseid:

• Kiirem testide täitmine: Isoleeritud testid töötavad palju kiiremini, kuna need ei hõlma keerulist seadistamist ega suhtlust väliste sõltuvustega. See kiirendab arendustsüklit ja võimaldab sagedasemat testimist.
• Fokuseeritud vigade tuvastamine: Kui test ebaõnnestub, on põhjus kohe selge, sest test keskendub ühele komponendile ja selle sisemisele loogikale. See lihtsustab silumist ja vähendab vigade tuvastamiseks ja parandamiseks kuluvat aega.
• Vähendatud sõltuvused: Isoleeritud testid on vähem vastuvõtlikud muudatustele rakenduse teistes osades. See muudab testid vastupidavamaks ja vähendab valepositiivsete või -negatiivsete tulemuste riski.
• Parem koodidisain: Isoleeritud testide kirjutamine julgustab arendajaid looma komponente selgete vastutusalade ja hästi määratletud liidestega. See soodustab modulaarsust ja parandab rakenduse üldist arhitektuuri.
• Parem testitavus: Komponente isoleerides saavad arendajad hõlpsasti sõltuvusi mockida või stubida, mis võimaldab neil simuleerida erinevaid stsenaariume ja äärmuslikke juhtumeid, mida reaalses keskkonnas võib olla raske reprodutseerida.

Tööriistad ja teegid Reacti ühiktestimiseks

Reacti ühiktestimise hõlbustamiseks on saadaval mitmeid võimsaid tööriistu ja teeke. Siin on mõned kõige populaarsemad valikud:

• Jest: Jest on JavaScripti testimisraamistik, mille on välja töötanud Facebook (nüüd Meta), mis on spetsiaalselt loodud Reacti rakenduste testimiseks. See pakub laia valikut funktsioone, sealhulgas mockimist, väidete teeke ja koodi katvuse analüüsi. Jest on tuntud oma kasutuslihtsuse ja suurepärase jõudluse poolest.
• React Testing Library: React Testing Library on kergekaaluline testimisteek, mis julgustab komponente testima kasutaja vaatenurgast. See pakub utiliitfunktsioonide komplekti komponentidega päringute tegemiseks ja nendega suhtlemiseks viisil, mis simuleerib kasutaja interaktsioone. See lähenemine soodustab testide kirjutamist, mis on tihedamalt seotud kasutajakogemusega.
• Enzyme: Enzyme on JavaScripti testimise utiliit Reactile, mille on välja töötanud Airbnb. See pakub funktsioonide komplekti Reacti komponentide renderdamiseks ja nende sisemiste osadega, nagu props, state ja elutsükli meetodid, suhtlemiseks. Kuigi seda kasutatakse endiselt paljudes projektides, eelistatakse uute projektide puhul üldiselt React Testing Library't.
• Mocha: Mocha on paindlik JavaScripti testimisraamistik, mida saab kasutada erinevate väidete teekide ja mockimisraamistikega. See pakub puhast ja kohandatavat testimiskeskkonda.
• Chai: Chai on populaarne väidete teek, mida saab kasutada Mocha või teiste testimisraamistikega. See pakub rikkalikku valikut väidete stiile, sealhulgas expect, should ja assert.
• Sinon.JS: Sinon.JS on eraldiseisev JavaScripti test spy'de, stub'ide ja mock'ide teek. See töötab mis tahes ühiktestimise raamistikuga.

Enamiku kaasaegsete Reacti projektide jaoks on soovitatav kombinatsioon Jest ja React Testing Library. See kombinatsioon pakub võimsat ja intuitiivset testimiskogemust, mis on hästi kooskõlas Reacti testimise parimate tavadega.

Testimiskeskkonna seadistamine

Enne ühiktestide kirjutamise alustamist peate seadistama oma testimiskeskkonna. Siin on samm-sammuline juhend Jesti ja React Testing Library seadistamiseks:

1. Paigalda sõltuvused:

               npm install --save-dev jest @testing-library/react @testing-library/jest-dom babel-jest @babel/preset-env @babel/preset-react
               
   
                 
                   Copy
                 
               
             

   • jest: Jesti testimisraamistik.
   • @testing-library/react: React Testing Library komponentidega suhtlemiseks.
   • @testing-library/jest-dom: Pakub kohandatud Jesti matchereid DOM-iga töötamiseks.
   • babel-jest: Teisendab JavaScripti koodi Jesti jaoks.
   • @babel/preset-env: Nutikas eelseadistus, mis võimaldab kasutada uusimat JavaScripti, ilma et peaksite haldama, milliseid süntaksi teisendusi (ja valikuliselt brauseri polüfille) teie sihtkeskkond (keskkonnad) vajavad.
   • @babel/preset-react: Babeli eelseadistus kõigi Reacti pluginate jaoks.
2. Seadista Babel (babel.config.js):

               module.exports = {
     presets: [
       ['@babel/preset-env', {targets: {node: 'current'}}],
       '@babel/preset-react',
     ],
   };
   
               
   
                 
                   Copy
                 
               
             

3. Seadista Jest (jest.config.js):

               module.exports = {
     testEnvironment: 'jsdom',
     setupFilesAfterEnv: ['<rootDir>/src/setupTests.js'],
     moduleNameMapper: {
       '\\.(css|less|scss)$': 'identity-obj-proxy',
     },
   };
   
               
   
                 
                   Copy
                 
               
             

   • testEnvironment: 'jsdom': Määrab testimiskeskkonnaks brauserilaadse keskkonna.
   • setupFilesAfterEnv: ['<rootDir>/src/setupTests.js']: Määrab faili, mis käivitatakse pärast testimiskeskkonna seadistamist. Seda kasutatakse tavaliselt Jesti seadistamiseks ja kohandatud matcherite lisamiseks.
   • moduleNameMapper: Käsitleb CSS/SCSS importimisi, neid mockides. See hoiab ära probleemid, mis tekivad stiililehtede importimisel teie komponentides. `identity-obj-proxy` loob objekti, kus iga võti vastab stiilis kasutatud klassi nimele ja väärtus on klassi nimi ise.
4. Loo setupTests.js (src/setupTests.js):

               import '@testing-library/jest-dom/extend-expect';
               
   
                 
                   Copy
                 
               
             

   See fail laiendab Jesti kohandatud matcheritega paketist `@testing-library/jest-dom`, näiteks `toBeInTheDocument`.

5. Uuenda package.json:

               "scripts": {
     "test": "jest",
     "test:watch": "jest --watchAll"
   }
               
   
                 
                   Copy
                 
               
             

   Lisa testiskriptid oma `package.json` faili testide käivitamiseks ja muudatuste jälgimiseks.

Esimese isoleeritud ühiktesti kirjutamine

Loome lihtsa Reacti komponendi ja kirjutame sellele isoleeritud ühiktesti.

Näidiskomponent (src/components/Greeting.js):

            import React from 'react';

function Greeting({ name }) {
  return <h1>Hello, {name || 'World'}!</h1>;
}

export default Greeting;
            

              
                Copy
              
            
          

Testifail (src/components/Greeting.test.js):

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

describe('Greeting komponent', () => {
  it('renderdab tervituse etteantud nimega', () => {
    render(<Greeting name="John" />);
    const greetingElement = screen.getByText('Hello, John!');
    expect(greetingElement).toBeInTheDocument();
  });

  it('renderdab tervituse vaikimisi nimega, kui nime pole ette antud', () => {
    render(<Greeting />);
    const greetingElement = screen.getByText('Hello, World!');
    expect(greetingElement).toBeInTheDocument();
  });
});
            

              
                Copy
              
            
          

Selgitus:

• `describe` plokk: Grupeerib seotud testid kokku.
• `it` plokk: Määratleb individuaalse testjuhtumi.
• `render` funktsioon: Renderdab komponendi DOM-i.
• `screen.getByText` funktsioon: Teeb DOM-ist päringu elemendi leidmiseks kindla tekstiga.
• `expect` funktsioon: Teeb väite komponendi väljundi kohta.
• `toBeInTheDocument` matcher: Kontrollib, kas element on DOM-is olemas.

Testide käivitamiseks täitke terminalis järgmine käsk:

            npm test
            

              
                Copy
              
            
          

Sõltuvuste mockimine

Isoleeritud ühiktestimisel on sageli vaja sõltuvusi mockida, et vältida väliste tegurite mõju testitulemustele. Mockimine hõlmab reaalsete sõltuvuste asendamist lihtsustatud versioonidega, mida saab testimise ajal kontrollida ja manipuleerida.

Näide: Funktsiooni mockimine

Oletame, et meil on komponent, mis hangib andmeid API-st:

Komponent (src/components/DataFetcher.js):

            import React, { useState, useEffect } from 'react';

async function fetchData() {
  const response = await fetch('https://api.example.com/data');
  const data = await response.json();
  return data;
}

function DataFetcher() {
  const [data, setData] = useState(null);

  useEffect(() => {
    async function loadData() {
      const fetchedData = await fetchData();
      setData(fetchedData);
    }

    loadData();
  }, []);

  if (!data) {
    return <p>Loading...</p>;
  }

  return <div><h2>Data:</h2><pre>{JSON.stringify(data, null, 2)}</pre></div>;
}

export default DataFetcher;
            

              
                Copy
              
            
          

Testifail (src/components/DataFetcher.test.js):

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

// Mockime fetchData funktsiooni
const mockFetchData = jest.fn();

// Mockime mooduli, mis sisaldab fetchData funktsiooni
jest.mock('./DataFetcher', () => ({
  __esModule: true,
  default: function MockedDataFetcher() {
    const [data, setData] = React.useState(null);

    React.useEffect(() => {
      async function loadData() {
        const fetchedData = await mockFetchData();
        setData(fetchedData);
      }
      loadData();
    }, []);

    if (!data) {
      return <p>Loading...</p>;
    }

    return <div><h2>Data:</h2><pre>{JSON.stringify(data, null, 2)}</pre></div>;
  },
}));

describe('DataFetcher komponent', () => {
  it('renderdab API-st hangitud andmed', async () => {
    // Määra mocki implementatsioon
    mockFetchData.mockResolvedValue({ name: 'Test Data' });

    render(<DataFetcher />);

    // Oota andmete laadimist
    await waitFor(() => screen.getByText('Data:'));

    // Veendu, et andmed on korrektselt renderdatud
    expect(screen.getByText('{"name":"Test Data"}')).toBeInTheDocument();
  });
});
            

              
                Copy
              
            
          

Selgitus:

• `jest.mock('./DataFetcher', ...)`: Mockib kogu `DataFetcher` komponendi, asendades selle algse implementatsiooni mockitud versiooniga. See lähenemine isoleerib testi tõhusalt kõigist välistest sõltuvustest, sealhulgas komponendi sees määratletud `fetchData` funktsioonist.
• `mockFetchData.mockResolvedValue({ name: 'Test Data' })` Määrab `fetchData` jaoks mockitud tagastusväärtuse. See võimaldab teil kontrollida mockitud funktsiooni poolt tagastatavaid andmeid ja simuleerida erinevaid stsenaariume.
• `await waitFor(() => screen.getByText('Data:'))` Ootab, kuni ilmub tekst "Data:", tagades, et mockitud API-kõne on enne väidete tegemist lõpule viidud.

Moodulite mockimine

Jest pakub võimsaid mehhanisme tervete moodulite mockimiseks. See on eriti kasulik, kui komponent sõltub välistest teekidest või utiliitfunktsioonidest.

Näide: Kuupäeva utiliidi mockimine

Oletame, et teil on komponent, mis kuvab vormindatud kuupäeva, kasutades utiliitfunktsiooni:

Komponent (src/components/DateDisplay.js):

            import React from 'react';
import { formatDate } from '../utils/dateUtils';

function DateDisplay({ date }) {
  const formattedDate = formatDate(date);
  return <p>The date is: {formattedDate}</p>;
}

export default DateDisplay;
            

              
                Copy
              
            
          

Utiliitfunktsioon (src/utils/dateUtils.js):

            export function formatDate(date) {
  return date.toLocaleDateString('en-US');
}
            

              
                Copy
              
            
          

Testifail (src/components/DateDisplay.test.js):

            import React from 'react';
import { render, screen } from '@testing-library/react';
import DateDisplay from './DateDisplay';
import * as dateUtils from '../utils/dateUtils';

describe('DateDisplay komponent', () => {
  it('renderdab vormindatud kuupäeva', () => {
    // Mockime formatDate funktsiooni
    const mockFormatDate = jest.spyOn(dateUtils, 'formatDate');
    mockFormatDate.mockReturnValue('2024-01-01');

    render(<DateDisplay date={new Date('2024-01-01T00:00:00.000Z')} />);

    const dateElement = screen.getByText('The date is: 2024-01-01');
    expect(dateElement).toBeInTheDocument();

    // Taasta algne funktsioon
    mockFormatDate.mockRestore();
  });
});
            

              
                Copy
              
            
          

Selgitus:

• `import * as dateUtils from '../utils/dateUtils'` Impordib kõik ekspordid `dateUtils` moodulist.
• `jest.spyOn(dateUtils, 'formatDate')` Loob spy `formatDate` funktsioonile `dateUtils` moodulis. See võimaldab teil jälgida funktsiooni väljakutseid ja selle implementatsiooni üle kirjutada.
• `mockFormatDate.mockReturnValue('2024-01-01')` Määrab `formatDate` jaoks mockitud tagastusväärtuse.
• `mockFormatDate.mockRestore()` Taastab funktsiooni algse implementatsiooni pärast testi lõppu. See tagab, et mock ei mõjuta teisi teste.

Isoleeritud ühiktestimise parimad tavad

Isoleeritud ühiktestimise eeliste maksimeerimiseks järgige neid parimaid tavasid:

• Kirjuta testid esimesena (TDD): Praktiseeri testipõhist arendust (TDD), kirjutades testid enne tegeliku komponendi koodi kirjutamist. See aitab selgitada nõudeid ja tagab, et komponent on disainitud testitavust silmas pidades.
• Keskendu komponendi loogikale: Keskendu komponendi sisemise loogika ja käitumise testimisele, mitte selle renderdamise detailidele.
• Kasuta tähendusrikkaid testide nimesid: Kasuta selgeid ja kirjeldavaid testide nimesid, mis peegeldavad täpselt testi eesmärki.
• Hoia testid lühikesed ja fokusseeritud: Iga test peaks keskenduma ühele komponendi funktsionaalsuse aspektile.
• Väldi liigset mockimist: Mocki ainult neid sõltuvusi, mis on vajalikud komponendi isoleerimiseks. Liigne mockimine võib viia testideni, mis on haprad ega peegelda täpselt komponendi käitumist reaalses keskkonnas.
• Testi äärmuslikke juhtumeid: Ära unusta testida äärmuslikke juhtumeid ja piirtingimusi, et tagada komponendi korrektne toimetulek ootamatute sisenditega.
• Säilita testi katvus: Püüdle kõrge testi katvuse poole, et tagada kõigi komponendi osade piisav testimine.
• Vaata üle ja refaktori teste: Vaata regulaarselt üle ja refaktori oma teste, et tagada nende asjakohasus ja hooldatavus.

Rahvusvahelistamine (i18n) ja ühiktestimine

Globaalsele publikule rakenduste arendamisel on rahvusvahelistamine (i18n) ülioluline. Ühiktestimine mängib olulist rolli tagamaks, et i18n on korrektselt implementeeritud ja et rakendus kuvab sisu erinevate lokaatide jaoks sobivas keeles ja vormingus.

Lokaadipõhise sisu testimine

Testides komponente, mis kuvavad lokaadipõhist sisu (nt kuupäevad, numbrid, valuutad, tekst), peate tagama, et sisu renderdatakse korrektselt erinevate lokaatide jaoks. See hõlmab tavaliselt i18n teegi mockimist või testimise ajal lokaadipõhiste andmete pakkumist.

Näide: Kuupäevakomponendi testimine i18n-iga

Oletame, et teil on komponent, mis kuvab kuupäeva, kasutades i18n teeki nagu `react-intl`:

Komponent (src/components/LocalizedDate.js):

            import React from 'react';
import { FormattedDate } from 'react-intl';

function LocalizedDate({ date }) {
  return <p>The date is: <FormattedDate value={date} /></p>;
}

export default LocalizedDate;
            

              
                Copy
              
            
          

Testifail (src/components/LocalizedDate.test.js):

            import React from 'react';
import { render, screen } from '@testing-library/react';
import { IntlProvider } from 'react-intl';
import LocalizedDate from './LocalizedDate';

describe('LocalizedDate komponent', () => {
  it('renderdab kuupäeva määratud lokaadis', () => {
    const date = new Date('2024-01-01T00:00:00.000Z');

    render(
      <IntlProvider locale="fr" messages={{}}>
        <LocalizedDate date={date} />
      </IntlProvider>
    );

    // Oota kuupäeva vormindamist
    const dateElement = screen.getByText('The date is: 01/01/2024'); // Prantsuse vorming
    expect(dateElement).toBeInTheDocument();
  });

 it('renderdab kuupäeva vaikelokaadis', () => {
    const date = new Date('2024-01-01T00:00:00.000Z');

    render(
      <IntlProvider locale="en" messages={{}}>
        <LocalizedDate date={date} />
      </IntlProvider>
    );

    // Oota kuupäeva vormindamist
    const dateElement = screen.getByText('The date is: 1/1/2024'); // Inglise vorming
    expect(dateElement).toBeInTheDocument();
  });
});
            

              
                Copy
              
            
          

Selgitus:

• `<IntlProvider locale="fr" messages={{}}>` Mähib komponendi `IntlProvider`-isse, pakkudes soovitud lokaati ja tühja sõnumite objekti.
• `screen.getByText('The date is: 01/01/2024')` Kontrollib, et kuupäev renderdatakse prantsuse vormingus (päev/kuu/aasta).

`IntlProvider`-it kasutades saate simuleerida erinevaid lokaate ja kontrollida, kas teie komponendid renderdavad sisu globaalsele publikule korrektselt.

Täiustatud testimistehnikad

Lisaks põhitõdedele on olemas mitmeid täiustatud tehnikaid, mis võivad teie Reacti ühiktestimise strateegiat veelgi täiustada:

• Snapshot-testimine: Snapshot-testimine hõlmab komponendi renderdatud väljundi hetktõmmise jäädvustamist ja selle võrdlemist varem salvestatud hetktõmmisega. See aitab tuvastada ootamatuid muutusi komponendi kasutajaliideses. Kuigi kasulikud, tuleks snapshot-teste kasutada kaalutletult, kuna need võivad olla haprad ja nõuda sagedasi uuendusi, kui kasutajaliides muutub.
• Omaduspõhine testimine: Omaduspõhine testimine hõlmab omaduste defineerimist, mis peaksid komponendi puhul alati paika pidama, sõltumata sisendväärtustest. See võimaldab teil testida laia valikut sisendeid ühe testjuhtumiga. Libraries like `jsverify` can be used for property-based testing in JavaScript.
• Juurdepääsetavuse testimine: Juurdepääsetavuse testimine tagab, et teie komponendid on ligipääsetavad puuetega kasutajatele. Tööriistu nagu `react-axe` saab kasutada juurdepääsetavuse probleemide automaatseks tuvastamiseks teie komponentides testimise ajal.

Kokkuvõte

Isoleeritud ühiktestimine on Reacti komponentide testimise fundamentaalne aspekt. Komponente isoleerides, sõltuvusi mockides ja parimaid tavasid järgides saate luua robustseid ja hooldatavaid teste, mis tagavad teie Reacti rakenduste kvaliteedi. Testimise varajane omaksvõtmine ja selle integreerimine kogu arendusprotsessi vältel viib usaldusväärsema tarkvara ja enesekindlama arendusmeeskonnani. Ärge unustage arvestada rahvusvahelistamise aspekte, kui arendate globaalsele publikule, ja kasutage täiustatud testimistehnikaid oma testimisstrateegia edasiseks täiustamiseks. Aja investeerimine õigete ühiktestimise tehnikate õppimisse ja rakendamisse tasub end pikemas perspektiivis ära, vähendades vigu, parandades koodi kvaliteeti ja lihtsustades hooldust.