Conţinut
- 01. Începeți cu biblioteca de testare React
- 02. Decideți ce să testați
- 03. Scrieți primul dvs. test
- 04. Utilizați funcția de curățare
- 05. Scrieți un test instantaneu
- 06. Proprietăți de testare
- 07. Testarea modificărilor în interfața de utilizare
- 08. Mock și Spy funcția
- 09. Începeți testarea aplicațiilor React
Dacă doriți să știți cum să testați React, sunteți în locul potrivit. Știți cu adevărat codul dvs. face ceea ce ar trebui să facă? Ați testat-o în browser? Ce se întâmplă dacă nu ați făcut-o sau nu puteți testa totul și se rupe în producție?
O bibliotecă de testare este un grup de utilitare pe care dezvoltatorii le folosesc pentru a scrie teste individuale pe componentele aplicației. Unele dintre principalele părți ale unui test sunt:
- Descriere: descrie despre ce este testul
- Utilizare / randare: folosește componenta într-un mediu în care poate fi testată
- Batjocoritor: creează funcții de pretenție, astfel încât să vă puteți verifica ipotezele
Pe parcursul acestui articol, voi explora câteva exemple din React Testing Library pentru a vă ajuta să începeți cu acest mod valoros de a îmbunătăți robustețea ieșirii codului dvs., precum și pentru a vă asigura că codul dvs. nu aruncă orice surprize urâte odată ce intră în producție.
Vrei mai multe resurse utile? Iată un rezumat al celor mai bune instrumente de design web care vă vor ajuta să lucrați mai inteligent. Sau dacă aveți nevoie de o mașină nouă, încercați acest rezumat al celor mai bune laptopuri pentru programare. Sau dacă creați un site nou, este posibil să aveți nevoie de un excelent constructor de site-uri web.
01. Începeți cu biblioteca de testare React
Voi folosi create-react-app pentru această demonstrație, deoarece vine deja preconfigurat cu biblioteca de testare. Dacă utilizați Gatsby sau o configurație personalizată, este posibil să aveți o configurație pe care trebuie să o rulați înainte de a începe să utilizați biblioteca de testare.
Pentru început, să creăm o aplicație nouă. Dacă aveți deja o versiune recentă a Node.js, puteți rula următoarea comandă fără a instala altceva la nivel global:
npx create-react-app netmag-javascript-testing
02. Decideți ce să testați
Imaginați-vă că avem o componentă simplă, să spunem un buton cu o anumită stare.Care sunt unele dintre lucrurile care trebuie testate într-o componentă ca aceasta?
● Aspectul componentei:
Nu vrem să se schimbe nimic în mod neașteptat după ce ne-am scris componenta. Deci, vom scrie un test instantaneu pentru a surprinde modul în care se redă. Apoi, dacă se schimbă ceva, îl vom vedea rapid fără un test manual sau vizual. Acest lucru este excelent pentru componentele care constau din multe componente mai mici: puteți vedea rapid când (și unde) aspectul său a fost afectat.
● Diferitele ramuri care redau:
Deoarece am putea avea două sau mai multe rezultate diferite, trebuie să testăm redarea corectă a tuturor, nu doar a unuia. Deci, trebuie să simulăm un eveniment de clic și să avem un alt test instantaneu pentru modul în care se redă după ce această ramură de cod a fost rulată.
● Funcțiile sunt apelate conform așteptărilor:
Vrem să ne asigurăm că codul pe care l-am scris pentru a apela o altă funcție funcționează așa cum presupunem că va funcționa. Dar, deoarece această funcție este o dependență externă, nu vrem să testăm asta aici. Testele noastre ar trebui să încapsuleze doar funcționalitatea pe care o dorim.
03. Scrieți primul dvs. test
Să scriem primul nostru test. Creați un fișier nou numit MyComponent.unit.test.js în același folder cu componenta. Adăugând test.js la final, acesta va fi ales automat de biblioteca de testare. Conținutul acelui fișier este mai jos:
import React din ‘reacționează’ import {randare} din ‘@ testing-library / react’ import MyComponent din ‘./MyComponent’ descrie (‘MyComponent />’, () => {// testele merg aici})
Primul lucru la care vreau să vă atrag atenția este descrie() funcție, care ia două argumente: primul este un șir pe care îl puteți utiliza pentru a descrie mai bine - ca un șir de text - ce va face testul dvs. În cazul nostru, am spus pur și simplu că ar trebui să redea. Acest lucru este foarte util atunci când altcineva se uită la codul dvs. sau trebuie să vă amintiți ce ați făcut într-o etapă ulterioară. Scrierea declarațiilor bune de descriere este o formă de documentare a codului și un alt motiv bun pentru scrierea testelor.
Al doilea argument este testele tale. descrie() funcția va rula toate aceste teste unul după altul.
04. Utilizați funcția de curățare
Să introducem o funcție de ajutor numită beforeEach (). Trebuie să folosim acest lucru, deoarece de fiecare dată când facem ceva cu componenta, dorim o copie nouă, fără recuzita pe care i-am trecut-o anterior, care încă nu există în componentă. Sau s-ar putea să trebuiască să redăm componenta: beforeEach () face asta pentru noi și îi putem trece funcția de curățare.
importați {redare, curățare} din „@ testing-library / react” ... descrie („componenta ar trebui să redea”, () => {beforeEach (cleanup)}
05. Scrieți un test instantaneu
În acest pas, vom „monta” componenta noastră (sau o vom reda).
descrie („componenta ar trebui să redea”, () => {înainte de fiecare (curățare) ea („redează cu elemente de recuzită de bază”, () => {redă (Componenta mea />)})}
Această redare ne oferă acces la toate proprietățile redate ale componentei compilate. Ar putea fi bine să aruncați acest lucru într-un console.log () astfel încât să puteți vedea mai clar ce face.
Dacă da, veți vedea că există câteva proprietăți utile pe care le putem profita aici. Voi face o afirmație (voi face o declarație testabilă) și o voi testa extragând containerul. Containerul „conține” nodurile DOM (toate codurile HTML) asociate componentei.
it (‘redează cu elemente de recuzită de bază’, () => {const {container} = redă (Componenta mea />)})
Acum avem acces la container, cum pot spune că este redat conform afirmației mele? Prin adăugarea unui test instantaneu.
Gândiți-vă la un instantaneu ca la o fotografie. Este nevoie de un instantaneu al componentei noastre într-un anumit moment. Apoi, ori de câte ori modificăm codul, putem vedea dacă acesta se potrivește cu instantaneul original. În caz contrar, putem fi siguri că nu s-a schimbat nimic în componentă. Cu toate acestea, dacă nu, este posibil să fi descoperit o problemă care provine dintr-o altă componentă, pe care s-ar putea să nu o fi observat anterior:
06. Proprietăți de testare
Accesoriile sau proprietățile unei componente pot fi testate și cu instantanee. Testarea diferitelor elemente de recuzită pe care le oferiți componentei dvs. vă va oferi o acoperire și o încredere mai mari. Nu știți niciodată când o cerință va însemna că elementele de recuzită ale componentei dvs. sunt refactorizate și rezultatul final se va schimba.
Adăugați următorul obiect în partea de sus a fișierului:
const lightProperties = {backgroundColour: ‘white’, textColour: ‘darkblue’}
Definim proprietățile dintr-un obiect și apoi folosim operatorul spread (trei puncte urmate de numele obiectului: ... lightproperties) deoarece putem transmite un singur argument atunci când redăm astfel. De asemenea, este util să vedeți ce proprietăți transmiteți izolat:
it ('redă cu recuzită de bază', () => {const {container} = redă (MyComponent />) expect (container) .toMatchSnapshot ()}) it ('redă cu recuzita versiunii ușoare', () => {const {container} = render (MyComponent {... lightProperties} />) expect (container) .toMatchSnapshot ()})
07. Testarea modificărilor în interfața de utilizare
Imaginați-vă că componenta noastră are un buton și doriți să vă asigurați că se întâmplă ceva când se face clic pe buton. S-ar putea să credeți că doriți să testați starea aplicației; de exemplu, ați putea fi tentat să testați dacă starea a fost actualizată. Cu toate acestea, acesta nu este obiectul acestor teste.
Acest lucru ne introduce într-un concept important în utilizarea unei biblioteci de testare: nu suntem aici pentru a testa starea sau modul în care funcționează componenta noastră. Suntem aici pentru a testa modul în care oamenii vor folosi componenta și dacă aceasta le îndeplinește așteptările.
Deci, dacă statul a actualizat sau nu este imaterial; ceea ce vrem să testăm este care este rezultatul apăsării acelui buton.
Să ne imaginăm că testăm rezultatul unei funcții care schimbă interfața de utilizare din modul întunecat în modul luminos. Iată componenta:
const modeToggle = () => {const [mode, setMode] = useState ['light'] const toggleTheme = () => {if (theme === 'light') {setTheme ('dark')} else {setTheme ('light')}} return (ToggleButton data-testid = ”mode-toggle” lightMode = {mode} onClick = {toggleMode}> Toggle mode / ToggleButton>)}
Mai întâi, ar trebui să adăugăm un id de test pe buton, astfel încât să îl putem găsi în faza de redare:
return (ToggleButton data-testid = ”mode-toggle” lightMode = {mode} onClick = {toggleMode}> Toggle mode / ToggleButton>
Ați observat că am adăugat noul atribut date-testid la buton? Iată cum ați putea testa acest lucru. Mai întâi, importați o nouă funcție, fireEvent din biblioteca de testare:
importați {cleanup, fireEvent, render} din „@ testing-library / react”
Putem folosi această funcție pentru a testa dacă există modificări în interfața de utilizare și că aceste modificări sunt consistente:
it ('redă cu elemente de sprijin de bază', () => {const {container} = redă (ToggleButton />) expect (container) .toMatchSnapshot ()}) it ('redă UI ușoară la clic', () => {const {container, getByTestId} = render (ToggleButton />) fireEvent.click (getByTestId ('mode-toggle')) expect (container) .toMatchSnapshot ()})
Acest lucru este minunat: nu trebuie să mergem manual pe site și să privim în jur, apoi să facem clic pe buton și să ne uităm a doua oară în jur - timp în care, ați putea recunoaște, probabil că veți uita sau veți rata ceva! Acum putem avea încredere că, având în vedere aceeași intrare, ne putem aștepta la aceeași ieșire în componenta noastră.
Când vine vorba de testarea ID-urilor, personal nu-mi place să folosesc date-testid pentru a găsi ceva în DOM. La urma urmei, obiectul testelor este de a imita ceea ce face utilizatorul și de a testa ce se întâmplă atunci când face. date-testid se simte ca un pic de înșelătorie - deși testidele de date vor fi foarte utile pentru inginerul dvs. de asigurare a calității (a se vedea box-ul Rolul inginerilor de asigurare a calității).
În schimb, am putea folosi getByText () și treceți în textul butonului nostru. Această metodă ar fi mult mai specifică comportamentului.
08. Mock și Spy funcția
Uneori s-ar putea să trebuiască să testăm un apel către o funcție, dar această funcție nu se află în sfera testului. De exemplu, am un modul separat care conține o funcție care calculează valoarea lui pi la un anumit număr de zecimale.
Nu trebuie să testez care este rezultatul acestui modul. Trebuie să testez că funcția mea funcționează conform așteptărilor. Pentru mai multe informații despre acest lucru, vă rugăm să consultați caseta Unități și teste de integrare. În acest caz, am putea „batjocori” această funcție:
const getPiValue = jest.fn () it ('apelează funcția la clic', () => {const {container, getByTestId} = render (ToggleButton />) fireEvent.click (getByTestId ('mode-toggle')) expect (getPiValue) .toHaveBeenCalledTimes (1))})
Functia toHaveBeenCalledTimes () este una dintre numeroasele funcții de asistență din biblioteca de testare care ne permit
pentru a testa ieșirea funcțiilor. Acest lucru ne permite nu numai să analizăm testele noastre doar către modulul pe care dorim să îl testăm, ci înseamnă și că putem „spiona” sau vedea ce face funcția noastră atunci când apelează acea funcție.
09. Începeți testarea aplicațiilor React
Testele de scriere pot părea puțin descurajante pentru început. Sper că acest tutorial v-a oferit un pic mai multă încredere să-l încercați. De când am început să scriu teste pentru aplicațiile mele, chiar nu mă pot întoarce: mă pot odihni mai ușor, știind că las în urmă o moștenire mult mai bună pentru cei care îmi vor folosi munca în viitor.
Pentru mai multe idei despre cum să vă testați componentele, accesați biblioteca de testare React sau exemple de testare React. Dacă sunteți în căutarea unor cursuri care să vă ajute să începeți, cel de Kent C Dodds (care a scris și menține React Testing Library) este popular. De asemenea, mi-a plăcut acest lucru la Tutorialele de creștere a nivelului, este cel care m-a determinat să scriu teste pentru codul meu.
Amintiți-vă, dacă construiți un site complex, veți dori să obțineți serviciul de găzduire web pe loc. Și dacă site-ul respectiv poate conține o mulțime de active, este crucial să le stochezi într-un spațiu de stocare cloud fiabil.
Acest conținut a apărut inițial în revista net. Citiți mai multe despre articole de design web aici.
