Komponentide testimine Reaktis: mida ja kuidas testida Jesti ja Ensüümiga.

Selle artikli reageerivate komponentide testimise kohta on kirjutanud Alona Pysarenko - Django Stari esiserver.
Loe originaalartiklit Django Stari ajaveebist.

Reacti komponentide testimine võib olla keeruline nii algajatele kui ka kogenud arendajatele, kes on juba testidega töötanud. Võib-olla on huvitav võrrelda oma lähenemisviise nendega, mida meie projektis kasutame. Koodbaasi katmiseks peate teadma, milliseid komponente tuleb testida ja millist koodi täpselt komponent peaks hõlmama.

Selle artikli ajal käsitlen järgmisi teemasid:

  • Määrake komponentide testimise õige järjekord projekti struktuuri põhjal
  • Otsige, mida testi katmiseks jätta (mida mitte testida)
  • Tehke kindlaks hetkeseisu testimise vajalikkus
  • Määratlege, mida ja millises järjekorras testida
  • Esitage üksikasjalikud kohandatud koodinäited

Artikkel nõuab, et teil oleks teadmisi Jesti ja ensüümi seadistamise kohta. Teavet installimise ja konfigureerimise kohta leiate hõlpsalt nende ametlikelt veebisaitidelt.

Eeldame järgmist juhtumit: Peate projekti koodialuse katma testidega. Millest peaksite alustama ja mida peaksite katsetamise lõpus saama? 100% testi katvus? See on mõõdupuu, mille poole peaksite püüdma, kuid enamikus olukordades te seda ei saavuta.

Miks? Sest te ei peaks kõiki koode katsetama. Saame teada, miks ja mida tuleks katsetest välja jätta. Veelgi enam, 100% testi katvus ei taga alati komponendi täielikku testimist. Samuti pole mingit garantiid, et see teavitab teid, kui midagi on muutunud. Ärge püüdke protsentide poole, vältige võltskatsete kirjutamist ja proovige lihtsalt põhikomponendi üksikasju mitte kaotada.

Komponentide testimise õige järjekorra määratlemine projekti struktuuri põhjal

Arutame seda küsimust projekti ülesehituse järgmises osas:

Võtsin jagatud kataloogi, kuna see on kõige olulisem. See koosneb komponentidest, mida kasutatakse projekti mitmel erineval lehel. Need on korduvkasutatavad ja tavaliselt on nad väikesed ega ole keerukad. Kui üks või teine ​​komponent ebaõnnestub, põhjustab see tõrke teistes kohtades. Sellepärast peaksime olema kindlad, kas need on õigesti kirjutatud. Selle kataloogi struktuur on jagatud mitmeks kaustaks, millest igaüks sisaldab komponente.

Kuidas määratleda jagatud kataloogis komponentide testimise õige järjekord:

  • Järgige alati reeglit, kuidas minna lihtsast keeruliseks. Analüüsige iga kataloogi ja määrake, millised komponendid on sõltumatud - nimelt ei sõltu nende renderdamine muudest komponentidest. Need on ise valminud ja neid saab eraldi kasutada ühe ühikuna. Ülaltoodud struktuuri järgi on see vormide kausta sisendite kataloog. See sisaldab reduksvormide sisendkomponente, nagu näiteks TextInput, SelectInput, CheckboxInput, DateInput jne.
  • Järgmisena peame määratlema abikomponendid, mida sageli kasutatakse sisendkomponentides, kuid neid tuleks testida eraldi. See on utils kataloog. Selle kausta komponendid pole keerukad, kuid väga olulised. Need on sageli korduvkasutatavad ja aitavad korduvate toimingute tegemisel.
  • Järgmine samm on määratleda, milliseid komponente saab ka iseseisvalt kasutada. Kui neid on, võtke need katsetamiseks. Meie ülesehitusest lähtuvalt on tegemist vidinatega, lihtsa funktsionaalsusega pisikomponentidega. Need on testkatte järjekorra kolmas punkt.
  • Lisaks analüüsige ülejäänud katalooge ja määratlege keerukamad komponendid, mida saab kasutada iseseisvalt või koos teiste komponentidega. Meie puhul on see modaalide kataloog. Neid komponente selgitatakse üksikasjalikult allpool.
  • Kõige keerukamad komponendid jäetakse lõpuni. Need on ajutine kataloog ja väljad vormide kaustast. Kuidas määratleda, millist neist tuleks kõigepealt katsetada? Võtan kataloogi, kust komponente on juba testitud komponentides kasutatud. Seega oli hoc kataloogis sisalduv komponent olemas vidinate komponendis. Sellepärast ma juba tean, kus ja mis eesmärgil seda kataloogi ja selle komponenti kasutatakse.
  • Viimane neist on väljade kaust. See sisaldab reduksvormidega ühendatud komponente.

Komponentide lõplik järjekord (meie näite põhjal) näeb välja järgmine:

Pärast seda järjekorda suurendate testitud komponentide keerukust samm-sammult. Seega on keerukamate komponentidega opereerimisel juba teada, kuidas väikseimad käituvad.

Ärge võtke näiteks välja massiivi testimiseks, kui te pole kindel, kuidas tekstivälja testida. Ärge võtke redutseeritud vormiga kaunistatud komponente, kui te pole vormi "vorm" ise testinud.

Olge oma valikutes järjekindel, ärge võtke esimest komponenti, mis teile pähe tuleb, ja muutke loogikat. Muidugi võib teie projekti struktuur erineda. Sellel võib olla ka muid katalooginimesid või täiendavaid komponente, toiminguid ja redutseerijaid, kuid komponentide testimise järjekorra määratlemise loogika on sama.

Määratlegem, mida tuleks testi katvuses ära jätta:

  • Kolmandate osapoolte raamatukogud. Ärge testige funktsionaalsust, mis on võetud teisest teegist. Te ei vastuta selle koodi eest. Jätke see vahele või jäljendage rakendust, kui vajate seda oma koodi kontrollimiseks.
  • Konstandid. Nimi räägib enda eest. Neid ei saa muuta. Need on staatilise koodi komplektid, mis ei ole ette nähtud muutmiseks.
  • Tekstilised stiilid (kui kasutate neid oma komponendis). Tekstiliste stiilide testimiseks peate objekti dubleerima testis olevate stiilidega. Kui objekti stiilid muutuvad, peate neid muutma ka testimisel. Ärge dubleerige testides komponendi koodi. Te ei pea kunagi meeles, et seda testides muuta. Pealegi ei saa teie kolleeg kunagi aru, et tegemist on dubleerimisega. Enamasti ei muuda tekstisisest stiilid komponendi käitumist, seetõttu ei tohiks neid testida. Erandiks võib olla see, kui teie stiilid muutuvad dünaamiliselt.
  • Asjad, mis pole testitud komponendiga seotud. Jäta vahele katmine testitavate komponentidega imporditud testkomponentidega. Olge ettevaatlik, kui see on mähitud teise sisse. Ärge katsetage ümbrist, vaid analüüsige ja testige neid eraldi.

Kuidas siis teste kirjutada? Kombineerin kahte testimismeetodit:

  • Hetkepiltide testimine
  • Komponentide loogika testimine

Arutlen neid mõlemaid nüüd.

Kuidas testida pilte

Snapshot Testing on kasulik testimisriist juhul, kui soovite olla kindel, et kasutajaliides pole muutunud. Esmakordselt selle testimisriistaga silmitsi seistes võib teil tekkida küsimusi, mis puudutavad hetkevõtete korraldamist ja haldamist. Põhimõte on väga lihtne, kuid kahjuks pole seda kuskil täielikult kirjeldatud.

1. samm. Kirjutage komponendi test ja kasutage ootusplokis meetodit .toMatchSnapshot (), mis loob hetktõmmise ise:

it ('renderda tekstikomponent õigesti', () => {
    const TextInputComponent = renderdaja.loome (). to JSON ();
    oodata (TextInputComponent) .toMatchSnapshot ();
});

2. samm. Kui käivitate testi esmakordselt ühel tasemel koos testiga, luuakse kataloog nimega __snapshots__, mille sees on automaatgenereeritud fail laiendiga.snap.

Ülevaade on järgmine:

// Jest Snapshot v1, https://goo.gl/fbAQLP
ekspordib [`Render TextInput õigesti komponent 1 '] =`

`;

3. samm. Lükake hetktõmmis hoidlasse ja salvestage see koos testiga.

Kui komponenti on muudetud, peate lihtsalt värskendama hetkepilti —updateSnapshot lipuga või kasutama lühivormi u lippu.

Nii et hetktõmmis luuakse - kuidas see töötab?

Vaatleme kahte juhtumit:

1. Komponent on muutunud

  • Käivitage testid
  • Luuakse uus hetktõmmis, seda võrreldakse automaatselt genereeritud hetktõmmisega, mis on salvestatud kataloogis __snapshots__
  • Testid ebaõnnestusid, kuna hetktõmmis on erinev

2. Komponent pole muutunud

  • Käivitage testid
  • Luuakse uus hetktõmmis, seda võrreldakse automaatselt genereeritud hetktõmmisega, mis on salvestatud kataloogis __snapshots__
  • Testid läbitud, kuna hetkevõte on identne

Kõik on hästi, kui katsetame väikest komponenti ilma loogikata (lihtsalt UI renderdamine). Kuid nagu praktika näitab, pole reaalsetes projektides selliseid komponente. Kui neid on, on neid vähe.

Kas komponentide täielikuks testimiseks on piisavalt pilte?

Komponentide katsetamise peamised juhised

1. Ühel komponendil peaks olema ainult üks hetktõmmis.

Kui üks pilt ebaõnnestub, siis tõenäoliselt ka teised. Ärge looge ja hoidke hunniku tarbetuid hetktõmmiseid, mis ummistavad ruumi ja ajavad segadusse arendajaid, kes loevad teie teste pärast teid.

Muidugi on erandeid, kui peate katsetama komponendi käitumist kahes olekus: näiteks komponendi olekus enne hüpikakna avamist ja pärast avamist.

Isegi sellise variandi saab alati selle asendada: esimene test salvestab komponendi vaikesätte ilma hüpikpildina hetktõmmiseta ja teine ​​test simuleerib sündmust ja kontrollib kindla klassi olemasolu. Sel viisil saate hõlpsalt mööda minna mitme pildi tegemisest.

2. Rekvisiitide testimine

Jagan rekvisiitide testimise reeglina kaheks testiks:

  • Esiteks kontrollige vaikeväärtuste renderdamist. Kui komponent renderdatakse, eeldan, et väärtus on võrdne defaultProps'iga juhul, kui sellel rekvisiidil on defaultProps.
  • Teiseks kontrollige rekordi kohandatud väärtust. Panen paika oma väärtuse ja eeldan, et selle saab pärast komponendi renderdamist.

3. Andmetüüpide testimine

Et testida, millist tüüpi andmeid rekvisiidid sisaldavad või milliseid andmeid pärast teatud toiminguid saadakse, saame kasutada spetsiaalset teegi jest-extension (Additional Jest matchers), millel on laiendatud vastete komplekt, mis puudub Jest. Selle raamatukogu abil on andmetüüpide testimine palju lihtsam ja nauditavam.

Prohvetüüpide testimine on seevastu vastuoluline küsimus. Mõned arendajad võivad vaielda proptüüpide testimise vastu, kuna see on kolmanda osapoole pakett ja seda ei tohiks testida. Sellegipoolest nõuan ma komponentide propüüpide testimist, kuna ma ei testi ise paketi funktsionaalsust. Selle asemel kinnitan lihtsalt, et prohvetüübid on õiged. Andmetüüp on väga oluline programmeerimisosa ja seda ei tohiks vahele jätta.

4. Ürituste testimine

Pärast läbilõike loomist ja rekvisiitide katmist testidega võite olla kindel, et komponent renderdab õigesti. Kuid sellest ei piisa täielikuks katmiseks juhuks, kui komponendis on sündmusi.

Sündmust saab kontrollida mitmel viisil. Kõige laialdasemalt kasutatakse:

  • pilkamatu sündmus => simuleerige seda => oodatakse sündmuse kutsumist
  • pilkav sündmus => simuleerige sündmust parameetritega => eeldatakse, et sündmust kutsuti möödunud parameetritega
  • läbida vajalikud rekvisiidid => renderduskomponent => sündmuse simuleerimine => oodata teatud käitumist kutsutud sündmuse korral

5. Katsetingimused

Väga sageli võivad teil olla tingimused konkreetse klassi väljastamiseks, koodi teatud sektsiooni renderdamiseks, vajalike rekvisiitide ülekandmiseks jne. Ärge unustage seda, sest vaikimisi väärtuste korral läbib testi ainult üks haru, teine ​​jääb testimata.

Komplekssetes arvutustes ja paljudes tingimustes sisalduvates komponentides võite mõne haru vahele jätta. Kontrollimaks, kas kõik koodi osad on kaetud testidega, kasutage testi katvuse tööriista ja kontrollige visuaalselt, millised oksad on kaetud ja millised mitte.

6. Testimisseisund

Oleku kontrollimiseks on enamikul juhtudel vaja kirjutada kaks testi:

  • Esimene kontrollib hetkeseisu.
  • Teine kontrollib olekut pärast sündmuse kutsumist. Render komponent => kõnefunktsioon otse testimisel => kontrollige, kuidas olek on muutunud. Komponendi funktsiooni kutsumiseks peate hankima komponendi eksemplari ja alles seejärel kutsuma selle meetodid (näide on toodud järgmises testis).

Pärast selle juhiste loendi läbimist kaetakse teie komponent 90 kuni 100%. Jätan 10% erijuhtudeks, mida ei olnud artiklis kirjeldatud, kuid võivad koodis esineda.

Testimise näited

Liikugem näidete juurde ja katame testidega komponente, nagu oleme ülalpool samm-sammult kirjeldanud.

1. Komponendi testimine vormidest / sisenditest.

Võtke vormide / sisendite kataloogist üks komponent. Olgu selleks kuupäevavalija välja komponent DateInput.js.

Testitud komponendi koodiloend: DateInput.js
Tundub, et:

Komponent DateInput kasutab teeki react-datepicker, millel on kaks utiliiti:

  • valueToDate (teisendab väärtuse kuupäevaks)
  • dateToValue (teisendab kuupäeva väärtuseks)

Pakett on ette nähtud kuupäevaga manipuleerimiseks ja PropTypes on React rekvisiitide kontrollimiseks.

Vastavalt komponendi koodile näeme vaikimisi rekvisiitide loendit, mis aitavad komponendil renderdada:

const defaultProps = {
    inputClassName: 'input-custom',
    kuudNäidatud: 1,
    dateFormat: 'PP.KM.AAAA',
    showMonthYearsDropdowns: false,
    minDate: moment ()
};

Hetktõmmise loomiseks sobivad kõik rekvisiidid, välja arvatud üks: minDate: moment (). hetk () annab meile iga kord, kui testi teeme, praeguse kuupäeva ja hetktõmmis ebaõnnestub, kuna see salvestab aegunud kuupäeva. Lahendus on seda väärt mõnitada:

const defaultProps = {
    minDate: hetk (0)
}

Igas renderdatud komponendis on vaja minDate prop. Rekvisiitide dubleerimise vältimiseks loon HOC, mis võtab vastu defaultProps ja tagastab ilusa komponendi:

impordi TestDateInput kataloogist '../DateInput';
const DateInput = (rekvisiidid) =>
    ;

Ärge unustage hetke-ajavööndit, eriti kui teie teste viivad läbi teistsuguses ajavööndis asuva riigi arendajad. Nad saavad pilkatud väärtuse, kuid ajavööndi nihkega. Lahenduseks on vaikimisi ajavööndi seadmine:

const moment = nõuda.requireAktuaalset ('hetk-ajatsoon') .tz.setDefault ('America / Los_Angeles')

Nüüd on kuupäeva sisestamise komponent testimiseks valmis:

1.Looge kõigepealt hetktõmmis:

it ('renderda kuupäeva komponent õigesti', () => {
    const DateInputComponent = renderdaja.loome () .JSON ();
    oodata (DateInputComponent) .toMatchSnapshot ();
});

2. rekvisiitide testimine:

Vaadake rekvisiidid läbi ja leidke olulised. Esimene katsetatud tugiteenus on showMonthYearsDropdowns. Kui see on tõene, kuvatakse kuu ja aasta rippmenüü:

see ('kontrollige kuu ja aasta rippmenüüd kuvatakse', () => {
    const rekvisiidid = {
            showMonthYearsDropdowns: tõsi
        },
        DateInputComponent = mount ().find('.datepicker ');
    oodata (DateInputComponent.hasClass ('reageeri-kuupäev-valija-peida-kuu')) .Equal (true);
});

Testige null prop väärtust. See kontroll on vajalik tagamaks, et komponent renderdatakse ilma määratletud väärtuseta:

it ('renderda kuupäeva sisestus õigesti nullväärtusega', () => {
    const rekvisiidid = {
            väärtus: null
        },
        DateInputComponent = mount ();
    oodata ((DateInputComponent) .prop ('väärtus')) .Equal (null);
});

3.Väärtuse testimine, eeldatav stringikeeld:

see ('kontrolli väärtuse tüüp', () => {
    const rekvisiidid = {
            väärtus: '10 .03.2018 '
        },
        DateInputComponent = mount ();
    oodata (DateInputComponent.prop ('väärtus')). toBeString ();
});

4.Testi sündmused:

Esiteks kontrollige sündmust onChange.

  • pilkamaMuuda tagasihelistamist
  • renderda kuupäeva sisestamise komponent
  • simuleerida muutuse sündmust uue sihtväärtusega
  • ja lõpuks kontrollige, kas onChange'i sündmusele on antud uus väärtus.
seda ('kontrollige onChange'i tagasihelistamist', () => {
    const onChange = jest.fn (),
        rekvisiidid = {
            väärtus: '20 .01.2018 ',
            onMuuda
        },
        DateInputComponent = mount ().find('input ');
    DateInputComponent.simulate ('muuda', {eesmärk: {väärtus: hetk ('2018-01-22')}});
    oodata (onChange) .toHaveBeenCalledWith ('22 .01.2018 ');
});

Järgmisena veenduge, et kuupäevavalija hüpik avaneb pärast kuupäeva sisestamisele klõpsamist. Selleks leidke kuupäeva sisestamine => simuleerige klõpsu sündmust => ja oodake hüpikakent, kui klass .react-datepicker on olemas.

see ('kontrolli DatePickeri hüpikakent avatud', () => {
    const DateComponent = mount (),
        dateInput = DateComponent.find ("input [type = 'text']");
    dateInput.simulate ('klõps');
    oodata (DateComponent.find ('. reageeri-kuupäeva valija')) toHaveLength (1);
});

Testide täielik loetelu: DateInput.test.js

2. Kasuliku testimine:

Testitud utiliidi koodiloend: valueToDate.js

Selle utiliidi eesmärk on muuta väärtus kohandatud vorminguga kuupäevaks.

Kõigepealt analüüsime antud utiliiti ja määratleme testimise peamised juhtumid:

  1. Selle utiliidi eesmärgi kohaselt muudab see väärtust, seega peame seda väärtust kontrollima:
  • Kui väärtust ei määratleta: peame olema kindlad, et utiliit ei tagasta erandit (viga).
  • Kui väärtus on määratletud: peame kontrollima, kas utiliit tagastab kuupäeva kuupäeva.

2. Tagastatud väärtus peaks kuuluma hetkeklassi. Seetõttu peaks see olema hetke näide.

3. Teine argument on dateFormat. Enne testimist seadke see konstantseks. Sellepärast läbitakse see igas testis ja väärtus saadakse vastavalt kuupäeva vormingule. Kas peaksime dateFormatit eraldi testima? Ma arvan, et ei. See argument on valikuline - kui me ei määra kuupäeva vormingut, siis utiliit ei katke ja see tagastatakse lihtsalt vaikevormingus. See on hetke töö, me ei peaks katsetama kolmanda osapoole raamatukogusid. Nagu ma juba mainisin, ei tohiks me unustada hetke-ajatsooni; see on väga oluline punkt, eriti erinevate ajavööndite arendajate jaoks.

Olgem kood:

  1. Esimesel juhul kirjutage test. Kui meil pole väärtust, on see tühi.
const formaat = 'PP.KM.AAAA';
it ('renderda väärtusToDate utiliit tühja väärtusega', () => {
    const value = valueToDate ('', formaat);
    oodata (väärtus) .toEqual (null);
});

2. Kontrollige, kas väärtus on määratletud.

const date = '21 .11.2015 ',
      formaat = 'PP.MM.AAAA';
it ('renderdatud väärtusToDate'i utiliit määratletud väärtusega', () => {
    const value = valueToDate (kuupäev, formaat);
    oodata (väärtus) .toEqual (hetk (kuupäev, formaat));
});

3. Kontrollige, kas väärtus kuulub hetkeklassi.

const date = '21 .11.2015 ',
    formaat = 'PP.KM.AAAA';
it ('kontrolliväärtus on hetke esinemispunkt', () => {
    const value = valueToDate (kuupäev, formaat);
    oodata (hetke väärtusväärtus) .toBeTruthy ();
});

Testide täielik loetelu: valueToDate.test.js

3. Vidinate testimine

Vidinate testimiseks võtsin spinnikomponendi.

Koodide loetelu testitud vidina kohta: Spinner.js

Näeb välja selline:

Spinnit pole selgituses vaja, kuna peaaegu kõigil veebiressurssidel on see komponent.

Nii et kui läheme katseid kirjutama:

  1. Esimene samm - pildi loomine:
it ('renderda õigesti Spinneri komponent', () => {
   const SpinnerComponent = kinnitus ();
   oodata (SpinnerComponent) .toMatchSnapshot ();
});

2. Rekvisiitide testimine:

Esiteks vaatame vaikepakkumise pealkirja ja kontrollime, kas see kuvatakse õigesti.

see ('vaikimisi kontrolli rekordi pealkirja', () => {
 const SpinnerComponent = kinnitus ();
    oodata (SpinnerComponent.find ('p'). tekst ()). toEqual ('Palun oodake');
});

Siis kontrollime kohandatud rekordi pealkirja. Peame kontrollima, kas see tagastab õigesti määratletud rekvisiidi. Vaadake koodi, pealkiri on mähitud rawMarkup utiliiti ja väljundid atribuudi ohtlikultSetInnerHTML abil.

Koodide loetelu rawMarkup util jaoks:

eksporti vaikimisi funktsioon rawMarkup (mall) {
    tagastama {__html: mall};
}

Kas peame ketramiskomponendisse lisama rawMarkupi testid? Ei, see on eraldi utiliit ja seda tuleks lisaks ketrajale katsetada. Meid ei huvita, kuidas see töötab - me peame lihtsalt teadma, et tiitliprofiil annab õige tulemuse.

Täpsustus: ohtlikultSetInnerHTML omaduse kasutamise põhjus on järgmine. Meie sait on mitmekeelne, selle eest vastutab tõlketurunduse meeskond. Nad saavad seda tõlkida lihtsalt sõnade kombinatsiooniga või isegi HTML-siltidega kaunistada, näiteks , , või isegi viilutada teksti loenditega

    ,
      . Me ei tea kindlalt, kuidas nad teksti tõlgivad ja kaunistavad. Peame kõik need asjad õigesti renderdama.

      Kombineerisin ühes testis kaks peamist testijuhtumit:

      • tagastage õige kohandatud rekordi pealkiri
      • renderdage rekordi pealkiri õigesti HTML-siltidega
      it ('kontrollige rekordi pealkirja html-siltidega', () => {
          const rekvisiidid = {
                  pealkiri: ' palun oodake '
              },
              SpinnerComponent = kinnitus ();
          oodata (SpinnerComponent.find ('p'). tekst ()). toEqual ('Palun oodake');
      });

      Võtke järgmine rekordi alapealkiri. See on valikuline ja seetõttu pole sellel vaikeseadet, nii et jätke samm vaikimisi rekvisiitide juurde ja katsetage kohandatud rekvisiite:

      • Kontrollige, kas alapealkirja rekvisiitides kuvatakse õigesti:
      const rekvisiidid = {
              alapealkiri: 'jäänud 1 minut'
          },
          SpinnerComponent = kinnitus ();
      it ('renderda õige tekst', () => {
          oodata (SpinnerComponent.find ('p'). punktis (1) .text ()) .Equal (rekvisiidid.subTitle);
      });

      Me teame, et alapealkiri on valikuline. Sellepärast peame vastavalt viilutamise märgistusele kontrollima, kas seda pole renderdatud vaikimisi rekvisiitidega. Kontrollige lihtsalt siltide arvu

      :

      see ('kontrolli, et alapealkiri pole renderdatud', () => {
        const SpinnerComponent = kinnitus ();
          oodata (SpinnerComponent.find ('p'). pikkus) .toEqual (1);
      });

      3.Teksti tüüpide katsetamine:

      • Pealkirja rekvisiidi puhul eeldatakse, et see on string:
      it ('kontrollige, kas pealkirja tüüp on string', () => {
          const rekvisiidid = {
                  pealkiri: "Oota"
              },
              SpinnerComponent = kinnitus ();
          oodata (SpinnerComponent.find ('p'). tekst ()). toBeString ();
      });
      • Subtiitrite jaoks mõeldud eeldatav string on ka:
      const rekvisiidid = {
              alapealkiri: 'jäänud 1 minut'
          },
          SpinnerComponent = kinnitus ();
      it ('Subtiitrite tüüp on string', () => {
          oodata (SpinnerComponent.find ('p'). punktis (1) .tekst ()). toBeString ();
      });

      Testide täielik loetelu: Spinner.test.js

      4. Modaalide testimine (ModalWrapper.js ja ModalTrigger.js)

      Tundub, et:

      Kuidas modaale testida?

      Kõigepealt tahan selgitada, kuidas meie projektis modaalid korraldatakse. Meil on kaks komponenti: ModalWrapper.js ja ModalTrigger.js.

      ModalWrapper vastutab hüpikpaigutuse eest. See sisaldab modaalmahutit, nuppu „sulge”, modaali pealkirja ja korpust.

      ModalTrigger vastutab ümbersuunamise eest. See sisaldab ModalWrapperi paigutust ja sisaldab sündmusi modali paigutuse juhtimiseks (avatud ja suletud toimingud).

      Lähen üle iga komponendi eraldi:

      1.Testitud komponendi koodiloend: ModalWrapper.js

      Olgem kood:

      Esiteks võtab ModalWrapper komponendi vastu ja muudab selle sees. Kõigepealt kontrollige, kas ModalWrapper ilma komponendita ei vea. Looge vaikimisi rekvisiitidega pilt:

      see ('ilma komponendita', () => {
          const ModalWrapperComponent = pinnapealne ();
          oodata (ModalWrapperComponent) .toMatchSnapshot ();
      });

      Järgmine samm on selle tegeliku seisundi simuleerimine rekvisiidi läbinud komponendi renderdamise abil:

      see ('koos komponendiga', () => {
         const rekvisiidid = {
                 komponent: () => {}
              },
              ModalWrapperComponent = pinnapealne ();
          oodata (ModalWrapperComponent) .toMatchSnapshot ();
      });

      Rekvisiitide testimine

      Klassi kohanime vastuvõtmise vastuvõtmine:

      it ('renderda õige klassi nimi', () => {
          const rekvisiidid = {
                  modalClassName: 'custom-class-name'
              },
              ModalWrapperComponent = pinnapealne ().find('Modal ');
              oodata (ModalWrapperComponent.hasClass ('kohandatud klassi nimi')). toEqual (true);
      });

      Kohandatud pealkirja ettepaneku saamine:

      it ('render õige pealkiri', () => {
          const rekvisiidid = {
                 pealkiri: 'ümbersuunamise pealkiri'
             },
             ModalWrapperComponent = pinnapealne ().find('ModalTitle ');
          oodata (ModalWrapperComponent.props (). lapsed) .toEqual ('Modaali pealkiri');
      });

      Õige näitusepakkumise saamine

      see ('kontrolli rekvisiidi väärtust', () => {
              const rekvisiidid = {
                     show: tõsi
                 },
                 ModalWrapperComponent = pinnapealne ().find('Modal ');
              oodata (ModalWrapperComponent.props (). näita) .toEqual (true);
          });

      Prohvetüüpide testimine

      • Näituse prop
      see ('kontrolli propsi', () => {
          const rekvisiidid = {
                 show: tõsi
              },
              ModalWrapperComponent = pinnapealne ().find('Modal ');
          oodata (ModalWrapperComponent.props (). näita) .toBeBoolean ();
      });
      • OnHide'i prop
      it ('renderda õige peitmise tüüp', () => {
          const rekvisiidid = {
                  onPeida: () => {}
              },
              ModalWrapperComponent = pinnapealne ().find('Modal ');
          oodata (ModalWrapperComponent.props (). onHide) .toBeFunction ();
      });
      • Komponentide jaoks
      it ('renderda õige komponendi tugitüüp', () => {
         const rekvisiidid = {
                 komponent: () => {}
             },
             ModalWrapperComponent = mount ();
         oodata (ModalWrapperComponent.props (). komponent) .toBeFunction ();
      });

      Testide täielik loetelu: ModalWrapper.test.js

      2.Testitud komponendi koodiloend: ModalTrigger.js

      Modaalne ümbris on kaetud testiga. Teine osa hõlmab modaalse päästiku komponenti.

      Komponentide ülevaade: see põhineb lülitatud olekus, mis näitab ModalWrapperi nähtavust. Kui lülitatakse: vale, hüpik on peidetud, muidu on see nähtav. Funktsioon open () avab alammenüü hüpikmenüü. Klõpsu sündmus ja funktsioon close () peidab hüpiknupu ModalWrapperis pakutaval nupul.

      Hetkepildi loomine:

      it ('renderdab ModalTriggeri komponendi õigesti', () => {
          const ModalTriggerComponent = pinnapealne ( 
      );     oodata (ModalTriggerComponent) .toMatchSnapshot (); });

      Kas peaksime ModalTriggerit testima komponentide rekvisiitidega? Ei - kuna komponent renderdatakse ModalWrapperi komponendi sees. See ei sõltu testitud komponendist. See oli kaetud juba ModalWrapperi testidega.

      Rekvisiitide testimine:

      Meil on üks tugilaps ja tahame olla kindlad, et meil on ainult üks laps.

      it ('veenduge, et teil oleks ainult üks laps (juhtelement)', () => {
          oodata (ModalTriggerComponent.findWhere (sõlm => node.key () === 'modal-control'). pikkus) .toEqual (1);
      });

      Prohvetüüpide testimine:

      Lastetugi peaks olema objekt, nii et kontrollige seda järgmises testis:

      const ModalTriggerComponent = kinnitus ( 
      );
      see ('kontrollige laste tugiteenuste tüüpi', () => {
            oodata (ModalTriggerComponent.props (). lapsed) .toBeObject ();
      });

      ModalTriggeri komponendi oluline osa on olekute kontrollimine.

      Meil on kaks osariiki:

      • Hüpik on avatud. Teadmiseks, et modaal on avatud, peame kontrollima selle olekut. Selleks helistage komponendi eksemplarist avatud funktsioonile ja oodake, et sisse lülitatud olek peaks olema tõene.
      see ('kontrollige, kas modaal on avatud', () => {
          const sündmus = {
              prevenDefault: () => {},
              stopPropagation: () => {}
          };
          ModalTriggerComponent.instance (). Avatud (sündmus);
          oodata (ModalTriggerComponent.state (). ümber lülitatud) .toBeTruthy ();
      });
      • Hüpik on suletud. Seda testitakse vastupidi, oleku sisselülitamine peaks olema vale.
      see ('kontrollige, kas modaal on suletud', () => {
         ModalTriggerComponent.instance (). Sulge ();
         oodata (ModalTriggerComponent.state (). ümber lülitatud) .toBeFalsy ();
      });

      Testide täielik loetelu: ModalTrigger.test.js

      Nüüd on modaalid täielikult testitud. Üks nõuanne üksteisest sõltuvate komponentide testimiseks: vaadake kõigepealt komponendid läbi ja kirjutage testiplaan, määratlege, mida peate igas komponendis testima, kontrollige iga komponendi testijuhtumeid ja veenduge, et te ei korrake mõlemas osas sama katsejuhtumit. Analüüsige hoolikalt võimalikke ja optimaalseid variante testi katmiseks.

      5. HOC testimine (kõrgema järgu komponent)

      Kaks viimast osa (HOC-d ja vormiväljade testimine) on omavahel ühendatud. Tahaksin teiega jagada, kuidas testida välja paigutust selle HOC-ga.

      Siin on selgitus, mis on BaseFieldLayout, miks me seda komponenti vajame ja kus seda kasutame:

      • BaseFieldLayout.js on vormide sisestuskomponentide, näiteks TextInput, CheckboxInput, DateInput, SelectInput jne, ümbris. Nende nimed lõppevad -Input-ga, kuna me kasutame redux-form paketti ja need komponendid on sisendkomponendid redux-vormi loogika jaoks.
      • Vormiväljade komponentide, st siltide, tööriistavihjete, prefikside (valuuta, ruutmeetri lühendid jne), ikoonide, vigade jms renderdamiseks on vaja BaseFieldLayoutit.
      • Me kasutame seda andmebaasis BaseFieldHOC.js sisendkomponendi põllupaigutusse mähistamiseks ja komponendi abil redigeerimisvormiga ühendamiseks.

      Testitud komponendi koodiloend: BaseFieldHOC.js

      See on HOC, mis võtab vormi sisestamise komponendi vastu ja tagastab komponendi, mis on ühendatud redux-vormiga.

      HOC analüüsimine:

      • See komponent võtab vastu ainult ühe rekomponendi, komponendi. Kõigepealt pean selle komponendi looma ja pakkima selle BaseFieldHOC-i.
      • Järgmisena pean kaunistatud mähitud HOC-i redutseerima, et väli oleks ühendatud redux-vormiga.
      • Renderdage see väli React Redux komponendi sees, et muuta pood testitavale komponendile kättesaadavaks. Poe pilkamiseks tehke lihtsalt järgmist.
      const pood = createStore (() => ({}));

      Nüüd, enne igat testi, pean tegema järgmist:

      lase BaseFieldHOCComponent;
      beforeEach (() => {
          const TextInput = () => {tagasta 'tekstisisestus'; },
              BaseFieldHOCWrapper = BaseFieldHOC (TextInput),
              TextField = reduxForm ({vorm: 'testForm'}) (BaseFieldHOCWrapper);
          BaseFieldHOCComponent = renderdaja.loome (
              
                  
              
          ) .toJSON ();
      });

      Pärast seda on komponent testimiseks valmis:

      1. Loo hetktõmmis:
      it ('renderda komponent korralikult', () => {
          oodata (BaseFieldHOCComponent) .toMatchSnapshot ();
      });

      2. Veenduge, et sisestuskomponent oleks pärast renderdamist mähitud BaseFieldLayout:

      see ('kontrolli, kas sisendkomponent on mähitud BaseFieldLayout' ', () => {
          oodata (BaseFieldHOCComponent.props.className) .toEqual ('vorm-rühm');
      });

      See on kõik, HOC on kaetud. Kõige keerulisem osa redux-vormiga seotud komponentide testimisel on põllu ettevalmistamine (kaunistamine redux-vormiga ja seadistuspood). Ülejäänud on lihtne, lihtsalt järgige juhiseid ja mitte midagi muud.

      Testide täielik loetelu: BaseFieldHOC.test.js

      6. Vormide / väljade testimine

      Välja HOC kaetakse testidega, et saaksime liikuda BaseFieldLayout komponendi juurde.

      Testitud komponendi koodiloend: BaseFieldLayout.js

      Lähme koodiks BaseFieldLayout.js ja kirjutame testid vastavalt ülaltoodud juhistele:

      1. Kõigepealt looge hetktõmmis.

      Seda komponenti ei renderdata ilma defaultPropsita:

      • inputComponent
      • Redaktorvormi poolt pakutavad rekvisiidid: sisend- ja metaobjektid. Sisestage omaduse nime ja metaga, millel on viga ja puudutatud:
      const defaultProps = {
         meta: {
              puudutatud: null,
              viga: null
          },
          sisend: {
              nimi: 'väli-nimi'
          },
          inputComponent: () => {tagasta 'test case'; }
      }

      Vaikimisi Propside kasutamiseks igas testitud ümbrises toimige järgmiselt.

      impordi TestBaseFieldLayout saidist '../BaseFieldLayout';
      const BaseFieldLayout = (rekvisiidid) => ;

      Nüüd oleme valmis hetktõmmise loomiseks:

      it ('renderdab korrektselt komponendi BaseFieldLayout', () => {
          const BaseFieldLayoutComponent = renderer.create () .JJS ();
          oodata (BaseFieldLayoutComponent) .toMatchSnapshot ();
      });

      2. Rekvisiitide testimine:

      Sellel komponendil on palju rekvisiite. Ma näitan näiteid mitmest ja ülejäänud testitakse analoogia põhjal.

      • Veenduge, et ikooni tugiteenus oleks õigesti esitatud
      it ('renderda ikooni tugiteenus õigesti', () => {
          const rekvisiidid = {
                  ikoon: 
              },
              BaseFieldLayoutComponent = mount ();
              oodata (BaseFieldLayoutComponent.find ('span'). hasClass ('icon-exclamation')). ​​toBeTruthy ();
      });
      • Veenduge, et tööriistavihje sisu muutuks sildi kõrval
      const rekvisiidid = {
              labelTooltipContent: 'sildi tööriistavihje'
          },
          BaseFieldLayoutComponent = mount ();
      see ('check prop renderdatud', () => {
         oodata (BaseFieldLayoutComponent.find ('span'). hasClass ('tooltip-icon')). ​​toBeTruthy ();
      });
      • Testimine fieldLink prop
      • Veenduge, et fieldLink oleks vaikimisi null
      it ('kontroll, et rekvisiit pole vaikimisi null', () => {
          const BaseFieldLayoutComponent = pinnapealne ();
          oodata (BaseFieldLayoutComponent.props (). fieldLink) .toBe (null);
      });
      • Veenduge, et väliLink kuvatakse õigesti kohandatud väärtusega

      3. Testimisvead:

      see ('kontrolli, kas väljal on viga', () => {
          const rekvisiidid = {
                  meta: {
                      puudutatud: tõsi,
                      viga: 'See väli on kohustuslik'
                  }
              },
              BaseFieldLayoutComponent = mount ();
          oodata (BaseFieldLayoutComponent.find ('. viga')). toHaveLength (1);
      });

      Testide täielik loetelu: BaseFieldLayout.test.js

      Alumine joon

      Nüüd teate, kuidas viia läbi projekti ülesehituse alusel komponentide täielikku katvust. Proovisin omast kogemusest selgitada, mida on vaja testida, mis järjekorras ja mida saate testide kattes jätta. Samuti demonstreerisin mitmete testimiskomponentide näiteid ja märkasin koodbaasi katvuse järjestust.

      Loodan, et see artikkel on teile kasulik ja jagab teie vastuseid. Täname, et lugesite

      Kui leiate, et see postitus on kasulik, koputage allolevat nuppu :) :)