Testiranje komponent v Reactu: kaj in kako preizkusiti z Jestom in Encimom.

Ta članek o testiranju reaktivnih komponent je napisala Alona Pysarenko - Frontend Engineer pri Django Stars.
Preberite izvirni članek na blogu Django Stars.

Testing React komponente so lahko zahtevne za začetnike in izkušene razvijalce, ki so že delali s testi. Morda bi bilo zanimivo primerjati lastne pristope s tistimi, ki jih uporabljamo v našem projektu. Če želite pokriti kodno bazo, morate vedeti, katere komponente je treba preizkusiti in katero kodo natančno v komponenti je treba zajeti.

V tem članku bom obravnaval naslednje teme:

  • Določite pravilen vrstni red testiranja komponent glede na strukturo projekta
  • Poiščite, kaj izpustiti v pokritju testa (česa ne preizkusiti)
  • Prepoznajte nujnost testiranja posnetkov
  • Določite, kaj želite preizkusiti v komponenti in v katerem vrstnem redu
  • Navedite podrobne primere kode po meri

Članek zahteva, da imate znanje o namestitvi Jest in Encima. Informacije o namestitvi in ​​konfiguraciji je enostavno najti na njihovih uradnih spletnih straneh.

Predpostavimo naslednji primer: Projektno kodno bazo morate pokriti s testi. S čim bi začeli in kaj bi morali dobiti ob koncu testiranja? 100% pokritost s testom? To je merilo, h kateremu bi si morali prizadevati, vendar ga v večini situacij ne boste dobili.

Zakaj? Ker ne bi smeli preizkušati vse kode. Ugotovili bomo, zakaj in kaj je treba izpustiti iz testov. Še več, stoodstotna pokritost s testom ne zagotavlja vedno, da je komponenta v celoti preizkušena. Prav tako ni nobenega zagotovila, da vas bo obvestil, če je bilo kaj spremenjeno. Ne prizadevajte za odstotke, izogibajte se pisanju ponarejenih testov in samo ne poskušajte izgubiti glavnih podrobnosti o komponentah.

Določitev pravilnega vrstnega reda testiranja komponent glede na strukturo projekta

O tem vprašanju razpravljamo v naslednjem delu strukture projekta:

Vzela sem skupni imenik, ker je najpomembnejša. Sestavljen je iz komponent, ki se uporabljajo na več različnih straneh projekta. So za večkratno uporabo in so običajno majhni in niso zapleteni. Če ena ali druga komponenta ne uspe, bo to povzročilo okvaro na drugih mestih. Zato bi morali biti prepričani, ali so napisane pravilno. Struktura tega imenika je razdeljena na več map, v katerih vsaka vsebuje komponente.

Kako določiti pravilen vrstni red testiranja komponent v imeniku v skupni rabi:

  • Vedno upoštevajte pravilo prehajanja od preprostega do zapletenega. Analizirajte vsak imenik in določite, katere komponente so neodvisne - namreč njihovo upodabljanje ni odvisno od drugih komponent. So samopopolne in jih lahko uporabljate ločeno kot eno samo enoto. Zgornja struktura je imenik vhodov v mapi obrazcev. Vsebuje vhodne komponente v redux obrazce, kot so TextInput, SelectInput, CheckboxInput, DateInput itd.
  • Nato moramo določiti pomožne komponente, ki se pogosto uporabljajo v komponentah za vhode, vendar jih je treba preizkusiti ločeno od njih. To je imenik utils. Sestavni deli v tej mapi niso zapleteni, vendar so zelo pomembni. Pogosto jih je mogoče ponovno uporabiti in pomagajo pri večkratnih ukrepih.
  • Naslednji korak je določitev, katere komponente se lahko uporabljajo tudi neodvisno. Če obstaja, jih vzemite za testiranje. Iz naše strukture so gradniki, majhne komponente s preprosto funkcionalnostjo. To bo tretja točka v čakalni vrsti za testno pokritost.
  • Nadalje analizirajte preostale imenike in določite bolj zapletene komponente, ki jih je mogoče uporabljati neodvisno ali v povezavi z drugimi komponentami. V našem primeru je to imenik modal. Te komponente bodo podrobno razložene spodaj.
  • Najbolj zapletene komponente so prepuščene koncu. So hoc imenik in polja iz mape z obrazci. Kako določite, katero je treba najprej preizkusiti? Vzamem imenik, iz katerega so že bile uporabljene komponente v preizkušenih komponentah. Tako je bila komponenta iz hoc imenika prisotna v komponenti gradnikov. Zato že vem, kje in za kakšen namen se uporablja ta imenik in njegova komponenta.
  • Zadnja je mapa polja. Vsebuje sestavne dele, povezane z reduksnimi oblikami.

Končni vrstni red komponent (na podlagi našega primera) bo izgledal tako:

Po tem vrstnem redu povečujete kompleksnost preizkušenih komponent korak za korakom. Tako, ko gre za delovanje s kompleksnejšimi komponentami, že veste, kako se obnašajo najmanjši.

Ne testirajte na primer polja „matrike“, če niste prepričani, kako preizkusiti polje z besedilom. Ne jemljite komponent, okrašenih v obliki reduks, če sami niste preizkusili polja „obrazec“.

Bodite dosledni pri svojih odločitvah, ne upoštevajte prve komponente, ki vam pride na misel, in preklopite na logiko. Seveda se lahko struktura vašega projekta razlikuje. Lahko ima druga imena imenikov ali ima dodatne komponente, dejanja in reduktorje, vendar je logika določanja vrstnega reda za testiranje komponent enaka.

Opredelimo, kaj naj v testnem poročilu izpustimo:

  • Knjižnice tretjih oseb. Ne preizkušajte funkcionalnosti, ki je bila vzeta iz druge knjižnice. Za to kodo niste odgovorni. Preskočite ga ali posnemajte izvajanje, če ga želite preizkusiti.
  • Konstante. Ime govori samo zase. Niso spremenljivi. So sklopi statične kode, ki niso namenjeni spreminjanju.
  • Vročni slogi (če jih uporabljate v svoji komponenti). Če želite preizkusiti vmesne sloge, morate objekt podvojiti s slogi v testu. Če se predmeti slogov spremenijo, jih morate spremeniti tudi v testu. V preskusih ne podvajajte kode komponente. Nikoli ne boste imeli v mislih, da bi ga spremenili v testih. Poleg tega vaš kolega nikoli ne bo ugotovil, da je prišlo do podvajanja. V večini primerov stili v rokah ne spremenijo obnašanja komponente, zato jih ne bi smeli preizkušati. Če se vaši slogi dinamično spreminjajo, je lahko izjema.
  • Stvari, ki niso povezane s preizkušeno komponento. Preskočite s preskusnimi komponentami, ki so bile uvožene v preizkušeno komponento. Bodite previdni, če je ovit v drugo. Ne testirajte ovoja, samo ga analizirajte in preizkusite posebej.

Kako torej dejansko pišete teste? Združim dva pristopa testiranja:

  • Testiranje posnetkov
  • Logično testiranje komponent

O obeh se bom pogovorila zdaj.

Kako preizkusiti s posnetki

Pregledovanje posnetkov je koristno orodje za testiranje, če želite biti prepričani, da se uporabniški vmesnik ni spremenil. Ko se prvič srečujete s tem orodjem za testiranje, boste morda imeli vprašanja v zvezi z organizacijo in upravljanjem posnetkov. Načelo je zelo preprosto, a žal ni bilo nikjer v celoti opisano.

Korak 1. Napišite test za komponento in v bloku pričakovanj uporabite metodo .toMatchSnapshot (), ki ustvari sam posnetek:

it ('pravilno ustvari besedilno komponento', () => {
    const TextInputComponent = renderer.create (). toJSON ();
    pričakujte (TextInputComponent) .toMatchSnapshot ();
});

Korak 2. Ko prvič preizkusite na eni ravni in skupaj s testom, se ustvari imenik z imenom __snapshots__ z avtogenerirano datoteko v notranjosti s pripono .snap.

Posnetek je videti takole:

// Jest Snapshot v1, https://goo.gl/fbAQLP
export [`Render TextInput pravilno komponenta 1`] =`

`;

Korak 3. Posnetek posnetka shranite v skladišče in ga shranite skupaj s testom.

Če je bila komponenta spremenjena, morate posnetek posodobiti z —updateSnapshot zastavo ali uporabiti kratki obrazec u zastavi.

Torej je posnetek ustvarjen - kako deluje?

Upoštevajmo dva primera:

1. Sestavni del se je spremenil

  • Izvedite teste
  • Ustvari se nov posnetek, ki ga primerja z samodejno ustvarjenim posnetkom, shranjenim v imeniku __snapshots__
  • Testi niso uspeli, ker je posnetek drugačen

2. Sestavni del se ni spremenil

  • Izvedite teste
  • Ustvari se nov posnetek, ki ga primerja z samodejno ustvarjenim posnetkom, shranjenim v imeniku __snapshots__
  • Testi so bili opravljeni, ker je posnetek enak

Vse je v redu, ko majhno komponento preizkusimo brez logike (samo upodabljanje uporabniškega vmesnika). A kot kaže praksa, na resničnih projektih ni takšnih komponent. Če obstajajo, jih je malo.

Ali je na voljo dovolj posnetkov za popolno testiranje komponent?

Glavna navodila za preskušanje komponent

1. Ena komponenta mora imeti samo en posnetek.

Če ena posneta ne uspe, bo verjetno odpovedala tudi druga. Ne ustvarite in shranite kup nepotrebnih posnetkov, ki zamašijo prostor in zmedejo razvijalce, ki bodo prebrali vaše teste za vami.

Seveda obstajajo izjeme, ko morate preizkusiti obnašanje komponente v dveh stanjih: na primer v stanju komponente pred odpiranjem pojavnega okna in po odprtju.

Toda tudi takšno različico lahko vedno nadomestimo s to: prvi test shrani privzeto stanje komponente brez pojavnega polja na posnetku, drugi test pa simulira dogodek in preveri prisotnost določenega razreda. Na ta način lahko preprosto zaobidete ustvarjanje več posnetkov.

2. Preizkušanje rekvizitov

Testiranje rekvizitov praviloma razdelim na dva testa:

  • Najprej preverite upodabljanje privzetih vrednosti podpor. Ko je komponenta upodobljena, pričakujem, da bo vrednost enaka defaultProps, če ima ta rekord defaultProps.
  • Drugič, preverite vrednost dodatka po meri. Nastavil sem svojo vrednost in pričakujem, da jo bo prejel po upodabljanju komponente.

3. Testiranje podatkovnih vrst

Če želite preizkusiti, kakšne vrste podatkov pridejo v rekvizite ali kakšne podatke dobimo po določenih dejanjih, lahko uporabimo posebno knjižnico, ki je dodano (Dodatna Jest matchers), ki ima razširjen nabor ujemanj, ki v oddelku niso na voljo. Jest. S to knjižnico je testiranje podatkovnih vrst veliko lažje in bolj prijetno.

Po drugi strani je testiranje protiptipov nasprotujoče si vprašanje. Nekateri razvijalci se lahko ugovarjajo proti preizkušanju prototipov, ker gre za tretji paket in ga ne bi smeli testirati. Kljub temu vztrajam pri preizkušanju vrst komponent, ker ne preizkušam same funkcionalnosti paketa. Namesto tega samo skrbim, da so proptiti pravilni. Vrsta podatkov je zelo pomemben programski del in ga ne smemo preskočiti.

4. Preskušanje dogodkov

Ko ustvarite posnetek in rekvizite pokrijete s testi, ste lahko prepričani, da bo komponenta pravilno prikazana. Vendar to ni dovolj za popolno pokritost, če imate v komponenti dogodke.

Dogodek lahko preverite na več načinov. Najbolj razširjene so:

  • priklicati dogodek => simulirati ga => pričakovati dogodek
  • mock dogodek => simuliraj dogodek s paramami => pričakovan dogodek je bil poklican s prenesenimi paramami
  • mimo potrebnih rekvizitov => upodobite komponento => simulirajte dogodek => pričakujte določeno vedenje ob klicanem dogodku

5. Pogoji testiranja

Zelo pogosto lahko imate pogoje za izhod določenega razreda, upodabljanje določenega odseka kode, prenos potrebnih rekvizitov ipd. Ne pozabite na to, kajti s privzetimi vrednostmi bo samo ena veja opravila test, druga pa bo ostala nepreverjena.

V zapletenih sestavnih delih z izračuni in veliko pogoji lahko zamudite nekatere veje. Če želite zagotoviti, da so vsi deli kode zajeti s preskusi, uporabite orodje za preskusno pokritje in vizualno preverite, katere veje so pokrite in katere ne.

6. Stanje testiranja

Če želite preveriti stanje, je v večini primerov potrebno napisati dva testa:

  • Prva preveri trenutno stanje.
  • Drugi preveri stanje, ko pokliče dogodek. Render komponenta => klicna funkcija neposredno v testu => preverite, kako se je stanje spremenilo. Če želite poklicati funkcijo komponente, morate dobiti primerek komponente in šele nato poklicati njene metode (primer je prikazan v naslednjem preizkusu).

Ko boste prešli ta seznam navodil, bo vaša komponenta pokrita od 90 do 100%. Za posebne primere, ki niso bili opisani v članku, pustim 10%, vendar se lahko pojavijo v kodi.

Primeri testiranja

Pojdimo na primere in s testi preizkusimo komponente, kot smo opisali zgoraj, korak za korakom.

1. Testiranje komponente iz obrazcev / vhodov.

Vzemite eno komponento iz imenika obrazcev / vnosov. Naj bo to DateInput.js, komponenta polja Datepicker.

Seznam kod za preizkušeno komponento: DateInput.js
Izgleda kot:

Komponenta DateInput uporablja izbirnik datuma reakcije knjižnice z dvema pripomočkoma:

  • valueToDate (pretvori vrednost v datum)
  • dateToValue (pretvori datum v vrednost)

Paket je za manipuliranje z datumom, PropTypes pa za preverjanje rekvizitov React.

Glede na kodo komponente lahko vidimo seznam privzetih rekvizitov, ki pomagajo komponenti prikazovati:

const defaultProps = {
    inputClassName: 'input-custom',
    mesecevPokazano: 1,
    dateFormat: 'DD.MM.YYYY',
    showMonthYearsDropdowns: false,
    minDatum: trenutek ()
};

Vsi rekviziti so primerni za ustvarjanje posnetka, razen enega: minDate: moment (). moment () nam bo dal trenutni datum vsakič, ko zaženemo test in posnetek ne bo uspel, ker shrani zastarel datum. Rešitev je v posmehu tej vrednosti:

const defaultProps = {
    minDatum: trenutek (0)
}

Za vsako upodobljeno komponento potrebujemo minDate podporo. Da se izognem podvajanju rekvizitov, ustvarim HOC, ki prejme defaultProps in vrne lepo komponento:

uvoz TestDateInput z '../DateInput';
const DateInput = (rekvizit) =>
    ;

Ne pozabite na časovni pas, še posebej, če bodo vaše teste izvajali razvijalci iz druge države v drugem časovnem pasu. Prejeli bodo posmešeno vrednost, vendar s premikom časovnega pasu. Rešitev je v nastavitvi privzetega časovnega pasu:

const moment = Require.requireActual ('moment-timezone'). tz.setDefault ('America / Los_Angeles')

Zdaj je komponenta za vnos datuma pripravljena za testiranje:

1.Najprej ustvarite posnetek:

it ('pravilno podaj komponento datuma', () => {
    const DateInputComponent = renderer.create (). toJSON ();
    pričakovati (DateInputComponent) .toMatchSnapshot ();
});

2. preizkusni rekviziti:

Poglejte skozi rekvizite in poiščite pomembne. Prva preizkušnja za preizkus je showMonthYearsDropdowns. Če je nastavljeno na true, se prikaže spustni seznam za mesec in leta:

it ('preverite prikazane spustne meseke in leta', () => {
    const rekviziti = {
            showMonthYearsDropdowns: res
        },
        DateInputComponent = mount ().find('.datepicker ');
    pričakovati (DateInputComponent.hasClass ('react-datepicker-hide-month')). toEqual (true);
});

Preizkusite ničelno vrednost opore. To preverjanje je potrebno za zagotovitev, da je komponenta upodobljena brez definirane vrednosti:

it ('prikaz vnosa datuma pravilno s ničelno vrednostjo', () => {
    const rekviziti = {
            vrednost: null
        },
        DateInputComponent = mount ();
    pričakovati ((DateInputComponent) .prop ('vrednost')). toEqual (null);
});

3.Test preizkusi za vrednost, datum, za katerega se pričakuje, da je niz:

it ('preverite vrsto vrednosti', () => {
    const rekviziti = {
            vrednost: '10 .03.2018 '
        },
        DateInputComponent = mount ();
    pričakovati (DateInputComponent.prop ('value')). toBeString ();
});

4.Test dogodki:

Najprej preverite dogodek onChange.

  • posmehuje seSpremeni povratnega klica
  • upodablja komponento vnosa datuma
  • simulirajte dogodek spremembe z novo ciljno vrednostjo
  • in končno preverite, ali je bil dogodek onChange poklican z novo vrednostjo.
it ('preverite povratni klic onChange', () => {
    const onChange = jest.fn (),
        rekviziti = {
            vrednost: '20 .01.2018 ',
            onSpremeni
        },
        DateInputComponent = mount ().find('input ');
    DateInputComponent.simulate ('sprememba', {cilj: {vrednost: moment ('2018-01-22')}});
    pričakujte (onChange) .toHaveBeenCalledWith ('22 .01.2018 ');
});

Nato se prepričajte, da se po izbranem datumu vpiše pojavno okno za izbiro datumov. Za to poiščite vnos datuma => simulirajte dogodek klika => in pričakujte pojavno okno, ko je prisoten izbirnik .react-datepicker.

it ('preverite pojavno okno DatePicker odprt', () => {
    const DateComponent = mount (),
        dateInput = DateComponent.find ("input [type = 'text']");
    dateInput.simulate ('klik');
    pričakovati (DateComponent.find ('. react-datepicker')) doHaveLength (1);
});

Celoten seznam testov: DateInput.test.js

2. Preizkušanje uporabnosti:

Seznam kod za preizkušeni pripomoček: valueToDate.js

Namen tega pripomočka je pretvoriti vrednost v datum z obliko zapisa po meri.

Najprej analiziramo navedeni pripomoček in določimo glavne primere za testiranje:

  1. Glede na namen te pripomočke pretvori vrednost, zato moramo to vrednost preveriti:
  • Če vrednost ni določena: moramo biti prepričani, da pripomoček ne bo vrnil izjeme (napake).
  • V primeru, da je določena vrednost: moramo preveriti, ali program vrne datum.

2. Vrnjena vrednost mora pripadati trenutnemu razredu. Zato bi moral biti primer trenutka.

3. Drugi argument je datumFormat. Pred preskusi ga nastavite kot konstantno. Zato bo podana pri vsakem preizkusu in vrnjena vrednost glede na obliko datuma. Bi morali datum forme testirati ločeno? Predvidevam, da ne. Ta argument ni izbiren - če ne nastavimo datumaFormat, se pripomoček ne bo prelomil in bo le vrnil datum v privzeti obliki. To je trenutek delo, ne bi smeli preizkušati knjižnic drugih proizvajalcev. Kot sem že omenil, ne bi smeli pozabiti na časovni pas; je zelo pomembna točka, zlasti za razvijalce iz različnih časovnih pasov.

Koda:

  1. Za prvi primer napišite test. Ko nimamo vrednosti, je prazna.
const format = 'DD.MM.YYYY';
it ('prikaže vrednostToDate pripomoček s prazno vrednostjo', () => {
    const value = valueToDate ('', oblika);
    pričakovati (vrednost) .toEqual (null);
});

2. Preverite, ali je določena vrednost.

const datum = '21 .11.2015 ',
      format = 'DD.MM.LLLL';
it ('prikaže vrednostToDate pripomoček z definirano vrednostjo', () => {
    const vrednost = valueToDate (datum, oblika);
    pričakovati (vrednost) .toEqual (trenutek (datum, oblika));
});

3. Preverite, ali vrednost pripada trenutnemu razredu.

const datum = '21 .11.2015 ',
    format = 'DD.MM.YYYY';
it ('vrednost preverjanja je instanceof moment', () => {
    const vrednost = valueToDate (datum, oblika);
    pričakovati (vrednost instanceof moment) .toBeTruthy ();
});

Celoten seznam testov: valueToDate.test.js

3. Testiranje gradnikov

Za testiranje pripomočkov sem vzel komponento spinnerja.

Seznam kod za preizkušeni pripomoček: Spinner.js

Izgleda nekako takole:

Spinner v obrazložitvi ni potreben, saj imajo skoraj vse spletne vire to komponento.

Če gremo torej pisati teste:

  1. Prvi korak - ustvarite posnetek:
it ('pravilno ustvari komponento Spinner', () => {
   const SpinnerComponent = mount ();
   pričakujte (SpinnerComponent) .toMatchSnapshot ();
});

2. preizkusni rekviziti:

Najprej si ogledamo privzeti naslov podpornika in preverimo, ali je pravilno prikazan.

it ('privzeto preverite naslov podpornika', () => {
 const SpinnerComponent = mount ();
    pričakujte (SpinnerComponent.find ('p'). text ()). toEqual ('Prosim počakajte');
});

Nato preverimo naslov prop po meri. Preveriti moramo, ali vrne pravilno definiran podpornik. Oglejte si kodo, naslov je zavit v orodje rawMarkup in izhod s pomočjo lastnosti lastnosti nevarnoSetInnerHTML.

Seznam kod za pripomoček rawMarkup:

izvoz privzete funkcije rawMarkup (predloga) {
    return {__html: predloga};
}

Ali moramo v komponento spinner vključiti teste za rawMarkup? Ne, gre za ločen pripomoček in ga je treba preizkusiti ločeno od predilnika. Vseeno nam je, kako to deluje - samo vedeti moramo, da podporni naslov prinaša pravilen rezultat.

Pojasnitev: Razlog za uporabo lastnosti nevarnoSetInnerHTML je naslednji. Naše spletno mesto je večjezično, za kar je odgovorna marketinška skupina za prevode. Lahko ga prevedejo preprosto s kombinacijo besed ali celo okrasijo z oznakami HTML, na primer , , ali celo rezino besedila s seznami

    ,
      . Ne vemo zagotovo, kako prevajajo in okrašujejo besedilo. Vse te stvari moramo pravilno narediti.

      V enem testu sem združila dva glavna testna primera:

      • vrne pravi naslov podpora po meri
      • pravilno podpišite naslov podpiranja z oznakami HTML
      it ('preverite naslov podpornika z html oznakami', () => {
          const rekviziti = {
                  naslov: ' Prosim počakajte '
              },
              SpinnerComponent = mount ();
          pričakujte (SpinnerComponent.find ('p'). text ()). toEqual ('Prosim počakajte');
      });

      Vzemite naslednji podnapis podpornika. Neobvezna je, zato nima privzete opore, zato preskočite korak s privzetimi rekviziti in preizkusite rekvizite po meri:

      • Preverite, ali je besedilo v podnaslovu podtita pravilno prikazano:
      const rekviziti = {
              podnaslov: 'levo 1 minuto'
          },
          SpinnerComponent = mount ();
      it ('upodabi pravilno besedilo', () => {
          pričakujte (SpinnerComponent.find ('p'). pri (1) .text ()). toEqual (props.subTitle);
      });

      Vemo, da podnaslov ni obvezen. Zato moramo preveriti, ali ni prikazan s privzetimi rekviziti, glede na oznako rezanja. Preverite samo število oznak

      :

      it ('check subTitle ni upodobljen', () => {
        const SpinnerComponent = mount ();
          pričakovati (SpinnerComponent.find ('p'). dolžina) .toEqual (1);
      });

      3.Testing vrste podpornikov:

      • Za podpornik naslova se pričakuje niz:
      it ('preveri vrsto podpor za naslov je niz', () => {
          const rekviziti = {
                  naslov: 'Počakaj'
              },
              SpinnerComponent = mount ();
          pričakujte (SpinnerComponent.find ('p'). text ()). toBeString ();
      });
      • Za podTitle se pričakuje tudi niz:
      const rekviziti = {
              podnaslov: 'levo 1 minuto'
          },
          SpinnerComponent = mount ();
      it ('tip za podTitle je niz', () => {
          pričakujte (SpinnerComponent.find ('p'). pri (1) .text ()). toBeString ();
      });

      Celoten seznam testov: Spinner.test.js

      4. Testiranje modalitet (ModalWrapper.js in ModalTrigger.js)

      Izgleda kot:

      Kako testirati modalce

      Najprej bi rad razložil, kako so modalci organizirani na našem projektu. Imamo dve komponenti: ModalWrapper.js in ModalTrigger.js.

      Za postavitev pojavnih oken je odgovoren ModalWrapper. Vsebuje modalni vsebnik, gumb "zapri", naslov modula in telo.

      Za ravnanje z modalci je odgovoren ModalTrigger. Vključuje postavitev ModalWrapper in vsebuje dogodke za nadzor načina postavitve (odprta in zaprta dejanja).

      Bom prešel vsako komponento posebej:

      1.Kod kotiranja za preizkušeno komponento: ModalWrapper.js

      Koda:

      Najprej ModalWrapper prejme komponento in jo postavi v notranjost. Najprej preverite, ali ModalWrapper ne bo uspel brez komponente. Ustvari posnetek s privzetimi rekviziti:

      it ('brez komponente', () => {
          const ModalWrapperComponent = plitvo ();
          pričakujte (ModalWrapperComponent) .toMatchSnapshot ();
      });

      Naslednji korak je simulacija njegovega dejanskega stanja z upodabljanjem komponent skozi rekvizite:

      it ('s komponento', () => {
         const rekviziti = {
                 komponenta: () => {}
              },
              ModalWrapperComponent = plitve ();
          pričakujte (ModalWrapperComponent) .toMatchSnapshot ();
      });

      Preizkušanje rekvizitov

      Prejemanje imena razreda po meri:

      it ('upiši pravilno ime razreda', () => {
          const rekviziti = {
                  modalClassName: 'ime-razreda po meri'
              },
              ModalWrapperComponent = plitve ().find('Modal ');
              pričakovati (ModalWrapperComponent.hasClass ('ime-razreda po meri')). toEqual (resnično);
      });

      Sprejem naslova po meri naslova:

      it ('upiši pravilen naslov', () => {
          const rekviziti = {
                 naslov: „Modal Title“
             },
             ModalWrapperComponent = plitve ().find('ModalTitle ');
          pričakujte (ModalWrapperComponent.props (). otroci) .toEqual ('Modal Title');
      });

      Prejemanje pravilne predstavitve:

      it ('preverite vrednost podpiranja', () => {
              const rekviziti = {
                     kažejo: res
                 },
                 ModalWrapperComponent = plitve ().find('Modal ');
              pričakovati (ModalWrapperComponent.props (). pokazati) .toEqual (true);
          });

      Testiranje vrst

      • Za razstavo
      it ('preverite vrsto podpiranja', () => {
          const rekviziti = {
                 kažejo: res
              },
              ModalWrapperComponent = plitve ().find('Modal ');
          pričakujte (ModalWrapperComponent.props (). pokaži) .toBeBoolean ();
      });
      • Za dodatni pogon
      it ('ponastavi pravilno onHide type prop', () => {
          const rekviziti = {
                  onHide: () => {}
              },
              ModalWrapperComponent = plitve ().find('Modal ');
          pričakujte (ModalWrapperComponent.props (). onHide) .toBeFunction ();
      });
      • Za podporno komponento
      it ('upodabi pravilno vrsto komponente tipa', () => {
         const rekviziti = {
                 komponenta: () => {}
             },
             ModalWrapperComponent = mount (

      Celoten seznam testov: ModalWrapper.test.js

      2.Kod kotiranja za preizkušeno komponento: ModalTrigger.js

      Modalni ovoj je bil pokrit s testom. Drugi del je pokrivanje modalne sprožilne komponente.

      Pregled komponent: temelji na preklopljenem stanju, ki kaže na vidljivost ModalWrapper-ja. Če preklopite: false, je pojavno okno skrito, sicer je vidno. Funkcija open () odpre pojavno okno na podrejenem elementu. Dogodek klika in funkcija close () skrije pojavno okno na gumbu, izdelan v ModalWrapper.

      Ustvarjanje posnetka:

      it ('sestavite ModalTrigger komponento pravilno', () => {
          const ModalTriggerComponent = plitve ( 
      );     pričakujte (ModalTriggerComponent) .toMatchSnapshot (); });

      Ali bi morali preizkusiti ModalTrigger z upodabljanjem komponent? Ne - ker bo komponenta upodobljena znotraj komponente ModalWrapper. Ni odvisno od preizkušene komponente. Ta je bila že pokrita s testi v modalWrapper tetih.

      Preskusni rekviziti:

      Imamo enega otroškega otroka in želimo biti prepričani, da imamo samo enega otroka.

      it ("zagotovite, da imate samo enega otroka (nadzorni element)", () => {
          pričakujte (ModalTriggerComponent.findWhere (vozlišče => node.key () === 'modal-control'). dolžina) .toEqual (1);
      });

      Preskusni načini:

      Otroški prop mora biti predmet, zato to preverite v naslednjem testu:

      const ModalTriggerComponent = mount ( 
      );
      it ('preverite vrsto otroškega podpiranja', () => {
            pričakujte (ModalTriggerComponent.props (). otroci) .toBeObject ();
      });

      Pomemben del komponente ModalTrigger je preverjanje stanja.

      Imamo dve državi:

      • Popup se odpre. Da vemo, da je modal odprt, moramo preveriti njegovo stanje. V ta namen pokličite odprto funkcijo iz primerka komponente in pričakujte, da bo preklopljeno stanje resnično.
      it ('preverite, ali je modal odprt', () => {
          const dogodek = {
              prevenDefault: () => {},
              stopPropagacija: () => {}
          };
          ModalTriggerComponent.in substance (). Odprto (dogodek);
          pričakujte (ModalTriggerComponent.state (). preklopljen) .toBeTruthy ();
      });
      • Popup je zaprt. Preizkušeno je obratno, vklopljeno stanje mora biti napačno.
      it ('preverite, ali je modal zaprt', () => {
         ModalTriggerComponent.in substance (). Close ();
         pričakujte (ModalTriggerComponent.state (). preklopljen) .toBeFalsy ();
      });

      Celoten seznam testov: ModalTrigger.test.js

      Zdaj so načini v celoti testirani. Nasvet za testiranje komponent, ki so med seboj odvisne: najprej preglejte komponente in napišite načrt preskusa, določite, kaj morate preizkusiti v vsaki komponenti, preverite primere preizkusov za vsako komponento in se prepričajte, da ne ponovite isti testni primer v obeh komponentah. Previdno analizirajte možne in optimalne variante za pokritost testa.

      5. HOC testiranje (komponenta višjega reda)

      Zadnja dva dela (testiranje HOC in polja obrazcev) sta med seboj povezana. Z vami bi želel deliti, kako preizkusiti postavitev polja z njegovim HOC.

      Tu je razlaga, kaj je BaseFieldLayout, zakaj potrebujemo to komponento in kje jo uporabljamo:

      • BaseFieldLayout.js je ovoj za vhodne komponente obrazca, kot so TextInput, CheckboxInput, DateInput, SelectInput itd. Njihova imena se končajo z -Input, ker uporabljamo paket redux oblike in so te komponente vhodne komponente za logiko v redux obliki.
      • Za izdelavo postavitve komponent polj obrazca potrebujemo BaseFieldLayout, to je upodabljanje nalepk, namigi, predpone (valuta, kratice kvadratnih metrov itd.), Ikone, napake in tako naprej.
      • Uporabljamo ga v programu BaseFieldHOC.js za zavijanje inputComponenta v postavitev polja in ga s pomočjo komponente povežemo z reduksno obliko.

      Seznam kod za preizkušeno komponento: BaseFieldHOC.js

      To je HOC, ki sprejme vhodno komponento obrazca in vrne komponento, povezano z obliko reduks.

      Analiza HOC:

      • Ta komponenta prejme samo eno podporno komponento. Najprej moram ustvariti to komponento in jo zaviti v BaseFieldHOC.
      • Nato moram okrasiti zavit HOC z obliko reduks, da se polje poveže z obliko reduks.
      • To polje podajte v komponento React Redux , da bo trgovina na voljo preizkušeni komponenti. Če se želite posmehiti trgovini, naredite samo:
      const store = createStore (() => ({}));

      Pred vsakim testom moram narediti naslednje:

      pustite BaseFieldHOCComponent;
      predEach (() => {
          const TextInput = () => {vrni 'vnos besedila'; },
              BaseFieldHOCWrapper = BaseFieldHOC (TextInput),
              TextField = reduxForm ({obrazec: 'testForm'}) (BaseFieldHOCWrapper);
          BaseFieldHOCComponent = renderer.create (
              
                  
              
          ) .toJSON ();
      });

      Po tem je komponenta pripravljena za testiranje:

      1. Ustvari posnetek:
      it ('sestavite pravilno sestavljeno komponento', () => {
          pričakujte (BaseFieldHOCComponent) .toMatchSnapshot ();
      });

      2. Po upodabljanju poskrbite, da je vhodna komponenta zavita v BaseFieldLayout:

      it ('komponenta za preverjanje vhoda je zavita v BaseFieldLayout', () => {
          pričakovati (BaseFieldHOCComponent.props.className) .toEqual ('skupina obrazcev');
      });

      To je vse, HOC je pokrit. Najbolj zapleten del pri preizkušanju komponent, povezanih z redux-formom, je priprava polja (okrasite z redux form in store setup). Ostalo je enostavno, samo upoštevajte navodila in nič drugega.

      Celoten seznam testov: BaseFieldHOC.test.js

      6. Preskušanje obrazcev / polj

      Polje HOC je pokrito s testi, tako da se lahko premaknemo na komponento BaseFieldLayout.

      Seznam kod za preizkušeno komponento: BaseFieldLayout.js

      Kode BaseFieldLayout.js in napišite teste v skladu z zgornjimi navodili:

      1. Najprej ustvarite posnetek.

      Ta komponenta ne bo upodobljena brez defaultProps:

      • inputComponent
      • Podpora rekvizita: vnos in meta predmeti. Vnos z imenom lastnosti in meta z napako lastnosti in dotaknjeno:
      const defaultProps = {
         meta: {
              dotaknil: ničelno,
              napaka: ničelna
          },
          vhod: {
              ime: 'ime-polja'
          },
          inputComponent: () => {return 'test case'; }
      }

      Če želite uporabiti defaultProps v vsakem preizkušenem ovoju, naredite naslednje:

      uvozi testBaseFieldLayout iz '../BaseFieldLayout';
      const BaseFieldLayout = (rekvizit) => ;

      Zdaj smo pripravljeni na posnetek:

      it ('pravilno predstavi komponento BaseFieldLayout', () => {
          const BaseFieldLayoutComponent = renderer.create (). toJSON ();
          pričakujte (BaseFieldLayoutComponent) .toMatchSnapshot ();
      });

      2. preizkusni rekviziti:

      Ta komponenta ima veliko rekvizitov. Pokazal bom primere iz več, ostale pa bom preizkusil po analogiji.

      • Prepričajte se, da je podpornik ikon pravilno izveden
      it ('ponastavi pravilno ikono podpiraj', () => {
          const rekviziti = {
                  ikona: 
              },
              BaseFieldLayoutComponent = mount ();
              pričakujte (BaseFieldLayoutComponent.find ('span'). hasClass ('ikona-klic')). toBeTruthy ();
      });
      • Prepričajte se, da je vsebina orodja prikazana poleg oznake
      const rekviziti = {
              labelTooltipContent: 'opis orodja za oznako'
          },
          BaseFieldLayoutComponent = mount ();
      it ('preverjanje je podprto', () => {
         pričakujte (BaseFieldLayoutComponent.find ('span'). hasClass ('tooltip-icon')). ​​toBeTruthy ();
      });
      • Preizkusno polje Povezava prop
      • Poskrbite, da bo polje FieldLink privzeto nično
      it ('check prop je privzeto ničelno', () => {
          const BaseFieldLayoutComponent = plitvo ();
          pričakujte (BaseFieldLayoutComponent.props (). field link) .toBe (null);
      });
      • Prepričajte se, da je FieldLink pravilno prikazan z vrednostjo po meri

      3. Napake pri testiranju:

      it ('preverite, ali ima polje napako', () => {
          const rekviziti = {
                  meta: {
                      dotaknil: res,
                      napaka: 'To polje je obvezno'
                  }
              },
              BaseFieldLayoutComponent = mount ();
          pričakujte (BaseFieldLayoutComponent.find ('. error')). toHaveLength (1);
      });

      Celoten seznam testov: BaseFieldLayout.test.js

      Spodnja črta

      Zdaj veste, kako opraviti testiranje komponent na celotni osnovi na podlagi strukture projekta. Iz lastnih izkušenj sem poskušal razložiti, kaj je potrebno preizkusiti, v kakšnem vrstnem redu in kaj lahko izpustiš v pokritju s testom. Predstavil sem tudi primere več komponent za testiranje in opazil zaporedje pokritosti kodne baze.

      Upam, da se vam bo ta članek zdel koristen in delil svoje odzive. Hvala za branje.

      Če se vam zdi ta objava uporabna, spodaj tapnite :) gumb :)