Jest 14.0: Testing av React-tre med øyeblikksbilder

Unofficial Beta Translation

This page was AI-translated by PageTurner (beta). Not officially endorsed by the project. Found an error? Report issue →

En av Jest-filosofiene er å tilby en integrert "nullkonfigurasjons"-opplevelse. Vi ønsker å gjøre det så friksjonsfritt som mulig å skrive gode og nyttige tester. Vi har observert at når ingeniører får tilgang til klare-å-bruke verktøy, ender de opp med å skrive flere tester, noe som igjen resulterer i stabile og sunne kodebaser.

Et av de store åpne spørsmålene var hvordan man effektivt skriver React-tester. Det finnes mange verktøy som ReactTestUtils og enzyme. Begge disse verktøyene er flotte og brukes aktivt. Likevel fortalte ingeniører oss ofte at de brukte mer tid på å skrive en test enn på selve komponenten. Som et resultat sluttet mange å skrive tester helt, noe som til slutt førte til ustabilitet. Ingeniører fortalte oss at alt de ønsket var å sikre at komponentene deres ikke endret seg uventet.

Sammen med React-teamet lagde vi en ny testrenderer for React og la til øyeblikksbildetesting i Jest. Se på denne eksempeltesten for en enkel Link-komponent:

import renderer from 'react-test-renderer';
test('Link renders correctly', () => {
  const tree = renderer
    .create(<Link page="http://www.facebook.com">Facebook</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot();
});

Første gang denne testen kjøres, oppretter Jest en øyeblikksbildfil som ser slik ut:

exports[`Link renders correctly 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function bound _onMouseEnter]}
  onMouseLeave={[Function bound _onMouseLeave]}>
  Facebook
</a>
`;

Øyeblikksbildartefaktet bør legges inn i versjonskontroll sammen med kodeendringer. Vi bruker pretty-format for å gjøre øyeblikksbilder menneskelesbare under kodegjennomgang. I påfølgende testkjøringer vil Jest bare sammenligne det renderte resultatet med forrige øyeblikksbilde. Hvis de samsvarer, består testen. Hvis de ikke samsvarer, har enten implementeringen endret seg og øyeblikksbildet må oppdateres med jest -u, eller så har testkjøringen funnet en feil i koden din som bør fikses.

Hvis vi endrer adressen som Link-komponenten i vårt eksempel peker til, vil Jest skrive ut dette resultatet:

Nå vet du at du enten må godta endringene med jest -u, eller fikse komponenten hvis endringene var utilsiktede. For å prøve denne funksjonaliteten, kan du klone snapshot-eksempelet, modifisere Link-komponenten og kjøre Jest. Vi har oppdatert React-opplæringen med en ny veiledning for øyeblikksbildetesting.

Denne funksjonaliteten ble bygget av Ben Alpert og Cristian Carlesso.

Eksperimentell støtte for React Native

Ved å bygge en testrenderer som ikke er knyttet til noen bestemt plattform, kan vi endelig støtte en full, umocket versjon av React Native. Vi er glade for å kunngjøre eksperimentell React Native-støtte for Jest gjennom pakken jest-react-native.

Du kan begynne å bruke Jest med react-native ved å kjøre yarn add --dev jest-react-native og legge til forhåndsinnstillingen i Jest-konfigurasjonen din:

"jest": {
  "preset": "jest-react-native"
}

• Opplæring og oppsettguide

• Eksempelprosjekt

• Eksempel pull request for snowflake, et populært react-native-bibliotek med åpen kildekode.

info

Forhåndsinnstillingen implementerer for øyeblikket bare det minimale settet med konfigurasjon som er nødvendig for å komme i gang med React Native-testing. Vi håper på bidrag fra fellesskapet for å forbedre dette prosjektet. Prøv det og rapporter problemer eller send pull requests!

Hvorfor øyeblikksbildetesting?

For Facebooks native apper bruker vi et system kalt "øyeblikksbildetesting": et testsystem som renderer UI-komponenter, tar et skjermbilde og deretter sammenligner et lagret skjermbilde med endringer gjort av en ingeniør. Hvis skjermbildene ikke samsvarer, er det to muligheter: enten er endringen uventet, eller så kan skjermbildet oppdateres til den nye versjonen av UI-komponenten.

Selv om dette var løsningen vi ønsket for nettet, oppdaget vi også mange problemer med slike end-to-end-tester som snapshot-integrasjonstester løser:

• Ingen flakiness: Siden testene kjøres i en kommandolinjekjører i stedet for en ekte nettleser eller telefon, trenger ikke testkjøreren å vente på bygg, starte nettlesere, laste inn sider eller manipulere grensesnittet for å nå forventet tilstand – noe som ofte gir ustabile resultater og støy.

• Rask iterasjonshastighet: Utviklere ønsker resultater på under ett sekund i stedet for å vente minutter eller timer. Hvis tester ikke kjører raskt som i de fleste end-to-end-rammeverk, kjører utviklere dem ikke i det hele tatt eller gidder ikke skrive dem.

• Feilsøking: Det er enkelt å gå inn i koden til en integrasjonstest i JS i stedet for å prøve å gjenskape screenshot-testscenarier og feilsøke visuelle differanser.

Siden vi tror snapshot-testing kan være nyttig utover Jest, delte vi funksjonaliteten i et eget jest-snapshot-pakke. Vi gleder oss til å samarbeide med fellesskapet for å gjøre den mer generell, slik at den kan integreres med andre testkjørere og dele konsepter og infrastruktur.

Til slutt, her er et sitat fra en Facebook-utvikler som beskriver hvordan snapshot-testing endret enhetstestopplevelsen:

"En av de største utfordringene i prosjektet mitt var å holde input- og output-filene for hver testcase synkronisert. Hver liten endring i funksjonalitet kunne føre til at alle output-filene endret seg. Med snapshot-testing trenger jeg ikke output-filene lenger – snapshots genereres gratis av Jest! Jeg kan bare inspisere hvordan Jest oppdaterer snapshots i stedet for å gjøre endringene manuelt." – Kyle Davis jobber med fjs.

Hva kommer nå for Jest

Nylig har Aaron Abramov begynt fulltid i Jest-teamet for å forbedre vår enhets- og integrasjonstestinfrastruktur for Facebooks annonseprodukter. De neste månedene planlegger Jest-teamet store forbedringer innen disse områdene:

• Erstatte Jasmine: Jasmine bremser oss og utvikles ikke aktivt. Vi har begynt å erstatte alle Jasmine-matcherne og gleder oss til å legge til nye funksjoner og fjerne denne avhengigheten.

• Dekningsgrad (Code Coverage): Da Jest opprinnelig ble laget, fantes ikke verktøy som Babel. Dekningsgradstøtten vår har mange edge cases og fungerer ikke alltid korrekt. Vi omskriver den for å løse dagens problemer.

• Utvikleropplevelse: Dette spenner fra forbedringer i oppsettsprosessen, feilsøking, CLI-forbedringer til mer dokumentasjon.

• Mocking: Mocksystemet, spesielt rundt manuelle mocks, fungerer dårlig og er forvirrende. Vi ønsker å gjøre det mer strengt og forståelig.

• Ytelse: Videre ytelsesforbedringer, spesielt for svært store kodebaser, er under arbeid.

Som alltid: hvis du har spørsmål eller vil hjelpe til, ta gjerne kontakt med oss!