Jest 27: Nye standarder for Jest, 2021-utgaven ⏩

Unofficial Beta Translation

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

I innlegget om Jest 26 for omtrent ett år siden, kunngjorde vi at etter to store versjoner med få brytende endringer, ville Jest 27 slå om noen brytere for å sette bedre standarder for prosjekter som er nye eller kan migrere problemfritt. Dette gir oss muligheten til å fjerne noen pakker fra standarddistribusjonen av Jest 28 og publisere dem som separat installerbare og pluggbare moduler i stedet. Alle som bruker de nye standardene kan dra nytte av en mindre installasjonsstørrelse, mens de som trenger disse pakkene fortsatt kan installere dem separat.

Med den første store endringen av standarder siden Nye standarder for Jest som kom med den banebrytende versjon 15, er Jest 27 nå her for å holde Jest rask, effektiv og relevant i fremtiden. Vi vil forklare disse standardendringene og andre bemerkelsesverdige brytende endringer i dette innlegget, men først, la oss se på noen spennende nye funksjoner!

Funksjonsoppdateringer

For det første kan den interaktive modusen du kanskje kjenner fra gjennomgang og oppdatering av mislykkede snapshots nå også brukes til å gå gjennom mislykkede tester en etter en. Æren går til førstegangsbidragsyter @NullDivision for å ha implementert denne funksjonen!

Når vi snakker om snapshots, er en av de mer spennende funksjonene vi har levert de siste årene Inline Snapshots, som landet i en mindre utgivelse av Jest 23 for nesten tre år siden. De kom imidlertid med begrensningen at prosjekter som ønsker å bruke dem, måtte bruke Prettier for å formatere koden sin, fordi det er det Jest ville bruke for å sikre at filen den skriver snapshots til forblir riktig formatert.
I løpet av disse årene har vi derfor hatt en pull request i pipelinen for å fjerne denne begrensningen og tillate bruk av Inline Snapshots uten Prettier. Den har samlet godt over hundre kommentarer, uten engang å ta hensyn til PRer som ble delt fra den og landet først, og skiftet til og med eier en gang etter den innledende innsendingen fra en annen førstegangsbidragsyter, @mmkal under den morsomme arbeidstittelen 'Uglier Inline Snapshots'. Med den strålende fremgangen til Prettier i nyere tid, er denne forbedringen kanskje mindre nødvendig enn i 2018, men likevel kjenner vi den følelsen av å komme inn i et prosjekt som ikke bruker Prettier, og plutselig ikke kunne bruke inline snapshots lenger. Aldri mer!

Hovedgrunnen til at det tok oss så lang tid å få dette på plass, var overraskende nok en minnefeil i byggepipelinen vår. Det viser seg at avhengighetene vi laster for hver testfil for å utføre parsing, snapshot-innsetting og utskrift, medfører en betydelig tids- og minnebelastning.
Med noen triks har vi sped opp initialiseringen per testfil med omtrent 70% sammenlignet med Jest 26. Merk at du nesten helt sikkert ikke vil se så stor ytelsesforbedring i ditt prosjekt – du ville trengt mange testfiler som hver kjører veldig raskt for å merke dette best, og overheaden ved bruk av et JSDOM-miljø overgår enhver slik forbedring.

I andre nyheter går støtten for native ESM fremover, men noen store kompleksiteter, for eksempel rundt mocking, ligger fremdeles foran oss, og vi fortsetter å se migreringen til ESM som et stort økosystemarbeid der Node og mange avgjørende verktøy og pakker alle må stole på hverandre for å levere en overbevisende helhetsopplevelse.
Støtte for ESM for å plugge moduler inn i Jest er mer avansert – egendefinerte kjøretidsmiljøer, rapporteringsverktøy, overvåkingsplugins og mange andre moduler kan allerede lastes som ES-moduler.

Vi har også slått sammen en PR for å håndtere testfiler som er symbolkoblet til testkatalogen, en funksjon mange brukere av Bazel etterspurte.

En annen PR gjorde transform asynkron, noe som er nødvendig for å støtte transpilering via verktøy som esbuild, Snowpack og Vite effektivt.

Endring av standardinnstillinger

Frem til nå har du, hvis du brukte Jest med standardkonfigurasjon, kanskje uten å vite det – kjørt kode som ble forgreinet for mange år siden fra testrammeverket Jasmine 2.0. Denne koden leverer testrammeverkfunksjoner som describe, it og beforeEach. I 2017 skrev Aaron Abramov en erstatning for Jasmine-koden kalt jest-circus, designet for å forbedre feilmeldinger, vedlikeholdbarhet og utvidbarhet.
Etter år med bruk i stor skala hos Facebook og i Jest selv, samt nylig adopsjon i create-react-app, er vi nå sikre på at jest-circus er svært kompatibelt med jest-jasmine2 og bør fungere i de fleste miljøer med minimal migreringsarbeid. Mindre forskjeller i utføringsrekkefølge og strenghet kan forekomme, men vi forventer ikke større problemer med mindre koden din er avhengig av Jasmine-spesifikke APIer som jasmine.getEnv(). Hvis du er avhengig av slike APIer, kan du gjenaktivere den Jasmine-baserte testkjøringen ved å konfigurere "testRunner": "jest-jasmine2".

Å kjøre tester i et JSDOM-miljø gir betydelig ytelsespåvirkning. Siden dette var standardoppførsel i Jest hvis ikke annet var konfigurert, kan brukere som utvikler Node-apper, for eksempel, ha fått et kostbart DOM-miljø de ikke trengte uten å vite det.
Derfor endrer vi standard testmiljø fra "jsdom" til "node". Hvis du påvirkes fordi du bruker DOM-APIer uten eksplisitt konfigurasjon, vil du motta feilmeldinger når du f.eks. aksesserer document. Du kan løse dette med "testEnvironment": "jsdom" eller miljøkonfigurasjon per fil.
For prosjekter med både tester som trenger DOM-miljø og tester som ikke gjør det, anbefaler vi å bruke det raske "node"-miljøet som standard, og kun merke tester som krever DOM med docblocks.
I neste hovedversjon planlegger vi å fjerne jest-jasmine2 og jest-environment-jsdom fra Jest-avhengighetstreet og kreve eksplisitt installasjon, slik at brukere kan dra nytte av mindre installasjonsstørrelse uten overflødig kode.

En annen standard vi endrer gjelder falske klokker (Timer Mocks). I Jest 26 introduserte vi en frivillig "moderne" implementering av falske klokker som bruker samme API, men med mer omfattende mocking (f.eks. for Date og queueMicrotask).
Denne moderne implementeringen blir nå standard. Hvis du er blant de få som er for sterkt påvirket av forskjellene til å migrere, kan du gjenopprette gammel oppførsel med jest.useFakeTimers("legacy") eller, hvis du aktiverer falske klokker globalt via konfigurasjon, "timers": "legacy".

Funksjoner med brytende endringer

Vi introduserte noen små brytende endringer for å forhindre utilsiktede feil ved å forby visse handlinger:

• Samme done-testtilbakekalling kan ikke kalles mer enn én gang,

• det kan ikke kombineres å kalle done og returnere et Promise,

• en describe-blokk må ikke returnere noe,

og vi gjorde noen TypeScript-typer strengere.

Moduler brukt i følgende konfigurasjonsalternativer transformeres nå som resten av koden din, noe som kan være bruddendringer hvis du har avhengighet av at de lastes uendret:

• testEnvironment

• runner

• testRunner

• snapshotResolver

Diverse bruddendringer

Vi har fjernet noen lenge avskrevne funksjoner:

• jest.addMatchers (bruk expect.extend i stedet)

• jest.resetModuleRegistry (bruk jest.resetModules i stedet)

• jest.runTimersToTime (bruk jest.advanceTimersByTime i stedet)

Mange av Jest-pakkene er migrert til ESM-eksporter (selv om de fortsatt leveres som CommonJS), så hvis du f.eks. bruker pretty-format direkte, må du kanskje justere importen din til en default-import.

Vi har droppet støtte for Node 13—men Jest støtter alltid Current og alle LTS-Node-versjoner, og Jest 27 fortsetter å støtte Node 10 som nylig ble uten vedlikehold.

Som alltid kan du se fullstendig endringslogg og liste over bruddendringer her.

Til slutt takker vi samfunnet for at Jest igjen fikk en himmelsk høy tilfredshet på 96% i State of JS 2020-undersøkelsen! Ta vare på dere, og vi håper dere fortsetter å like å bruke Jest i årene og versjonene som kommer! 🃏