Menu

Jest-konfiguration og fejlfinding Jest-baserede tests

  • Vigtigste
  • Andet
  • Jest-konfiguration og fejlfinding Jest-baserede tests

jest configuration debugging jest based tests

Prøv Vores Instrument Til At Fjerne Problemer

Lær om Jest Config, debugging og sammenligning af Jest med andre JavaScript-testrammer specifikt Jest vs Mocha & Jest vs Jasmine:

Heri Informativ Jest-serie , vi udforskede alt om Test af React Apps, Mocks and Spies ved hjælp af Jest i vores sidste tutorial.

I denne vejledning lærer vi mere om Jest Config-filer og ser, hvordan du rent faktisk kan fejle Jest-tests til fejlfinding af en eller flere multiple tests.

Vi vil også undersøge nogle af de almindeligt anvendte indstillinger i Jest Config-filen, der kan konfigureres uafhængigt af et projekt, eller dem, der kan tilføjes som en del af selve package.json-konfigurationen.

Jest-konfiguration og fejlfinding

Vi bruger Visual Studio-kode til at skrive vores Jest-tests og bruger en udvidelse eller et plugin i VS-kode for at muliggøre debugging-support til Jest-tests.

Derudover sammenligner vi de forskellige Javascript-testrammer som Mocha og Jasmine med Jest og forstår fordelene og ulemperne ved hinanden.

Hvad du vil lære:

tjærekommando i unix med eksempler

Der er Config

Jest-konfiguration kan specificeres på 3 måder

  • Gennem en nøgle i package.json-fil.
  • Gennem en jest.config.js-fil - Konfigurationsfil skrevet som et modul.
  • Gennem en JSON, der kunne bruges med indstillingen som –config-flag.

Med alle ovenstående tilgange kan du opnå det samme resultat. Lad os se det første trin - dvs. tilføje Jest-konfiguration via en nøgle i package.json-filen.

I den eksisterende package.json-fil skal du tilføje en ny nøgle ved navn “jest”. Dette er intet andet end et sæt nøgleværdipar i JSON-format. Alle konfigurationsindstillinger relateret til Jest kan tilføjes yderligere til dette afsnit i filen package.json.

tilføj konfigurationsindstillinger

De mest anvendte konfigurationsindstillinger er angivet nedenfor.

# 1) Dækningsrelateret

collectCoverage, dækningTærskel, dækningReportere, dækningKatalog - Dette er de mest anvendte muligheder. Dækning er en vigtig måling, og den sikrer, at koden testes mod en forudindstillet tærskel.

En detaljeret forklaring af hver af dem er som følger:

# 1) collectCoverage: Denne mulighed bruges til at angive, om vi vil have Jest-testløberen til at indsamle oplysninger om dækning eller ej. Når Jest-løberen er indstillet til sand, indsamler den dækningsoplysningerne. Med denne mulighed samles dækningen og vises på konsollen i slutningen af ​​testudførelsen som vist nedenfor.

# 2) dækning tærskel: Denne indstilling giver os mulighed for at specificere tærskelværdierne for dækning i procent. Dette er meget nyttigt, når organisationen eller teamet ønsker at overholde en bestemt minimumsdækningsværdi, uden hvilken ingen kode kan skubbes eller flettes til hovedgrenen.

Lad os se, hvordan dette kan bruges.

Dækning kan specificeres på globalt niveau, filniveau eller enhver anden regex. Når det er angivet på globalt niveau, skal alle de angivne tærskler matche for de samlede filer i projektet.

'coverageThreshold': { 'global': { 'branches':95, 'functions':100, 'lines':70, 'statements':-2 } }

Det er også muligt at specificere dækning på filniveau ved at ændre “global” til filnavn eller regex. Tærskelkonfigurationerne kan variere afhængigt af kravet.

'coverageThreshold': { './src/calculator.js': { 'branches':100, 'functions':100, 'lines':100, 'statements':-10 } }

# 3) dækning Denne konfiguration bruges til at specificere, hvilken reporter du vil bruge til at generere dækningsrapporten. Der er mange eksisterende journalister som NPM-pakker til rådighed, der kan bruges til at generere en dækningsrapport i slutningen af ​​testudførelsen.

# 4) dækningskatalog: Denne indstilling giver brugeren mulighed for at specificere det bibliotek, hvor dækningsrapporterne skal gemmes eller vedvares, efter at de er oprettet.

Nedenfor er et kombineret eksempel på brug af alle dækningsrelaterede konfigurationsindstillinger.

'jest':{ 'collectCoverage':true, 'coverageThreshold': { 'global': { 'branches':95, 'functions':100, 'lines':70, 'statements':-2 }, './src/calculator.js': { 'branches':100, 'functions':100, 'lines':100, 'statements':-10 } }, 'coverageReporters': ( 'lcov','text' ), 'coverageDirectory': './output/code-coverage/' }

Her har vi brugt 2 dækningsreportere, dvs. lcov og text.Lcov er Linux's liniedækning og er som standard til stede, og 'tekst' -reporteren betyder, at dækningsoutputtet også vises på konsollen. Dækningsrapporten genereres på den sti, der er angivet i indstillingen 'dækningskatalog'.

er-dækning bibliotek

# 2) Mock-relateret

Mocks bruges meget under test med Jest. Begge nedenstående konfigurationsindstillinger tillader nem konfiguration og rydning af mocks.

  • autoMocks: Når det er indstillet til sandt, vil dette spotte alle de moduler, der importeres til testen som standard.
  • clearMocks: Når det er indstillet til sandt, rydder dette alle de spottede opsætninger / moduler efter hver test, så hver test starter med en ny tilstand. Dette kan også opnås ved hjælp af testCleanup eller 'efter' -metoden, men det er endnu nemmere at have det konfigureret.

# 3) Relaterede tests

# 1) testTimeout: Denne konfiguration bruges til at give en hård timeout-indstilling til tests i millisekunder. Enhver test, der tager mere end denne konfigurerede tærskel, markeres mislykkedes på grund af timeout-undtagelse.

'jest' { 'testTimeout': 100 }

# 2) Global: Denne konfiguration bruges til at indstille globale variabler, der skal være tilgængelige med hver test.

'jest' { 'globals': { 'globalVar': 'test global variable!' } }

Lad os prøve at bruge en global variabel i testen og se om den fungerer som forventet.

describe('Calculator tests', () => { test('add 2 numbers', () => { // arrange & act const val = mathOps.sum(3,4) console.log(globalVar) // assert expect(val).toBe(7) })

Efter udførelse af denne test skal værdien af ​​globalVar logges.

er_output

Kontrollere her for en udtømmende liste over alle konfigurationsindstillinger.

Videovejledning om IS-konfiguration

Fejlfinding med Jest

I dette afsnit vil vi forsøge at forstå, hvordan vi kan fejle tests, der er skrevet baseret på Jest.

Vi anvender og forstår 2 forskellige måder, hvorpå vi kan fejle Jest-tests.

  1. Node's native debugger og derefter bruge Chrome Inspector til at fejle testene.
  2. Brug af Visual Studio Codes fejlfindingskonfiguration til at fejle testene i selve Visual Studio Code-editoren. Dette er den mest almindelige måde at debugge på, da Visual Studio Code er den valgte standardeditor for det meste af Javascript-udviklingen i disse dage.

Hver af disse tilgange forklares nedenfor detaljeret.

# 1) Brug af Node's Native Debugger

For at bruge Node JS native debugger er vi nødt til at indsætte nøgleordet 'debugger' i testen, hvor vi vil placere brudpunktet.

Når testudføreren støder på debugger kommando, det sætter udførelsen på pause, og hvis vi vedhæfter chrome-fejlfindingsværktøjer, kan vi fejle testkoden (såvel som funktionen under test) ved hjælp af Chrome-værktøjer.

Chrome-browseren er en forudsætning her for at kunne bruge Node's Native Debugger.

Følg nedenstående trin.

hvordan man tilføjer elementer til en matrix

# 1) Tilføj debugger-nøgleord inden for testen, dvs. på det punkt, hvor du vil have, at testen skal ramme brudpunktet, indsæt kommandoen 'debugger'

#to) Udfør testen ved hjælp af –inspect-brk flag.

Brug nedenstående kommando til at udføre testen i en breakpoint-tilstand.

/usr/local/bin/node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand

# 3) Vedhæft nodens fejlfinding i Chrome. Nu i Chrome-browseren skal du navigere til chrome: // inspicere og oprette forbindelse til den mållytter, der er oprettet ved ovenstående trin.

Node

# 4) Fortsæt udførelsen, og du vil se, at brudpunktet rammer i chrome-fejlfindingsinspektøren, og du kan debugge opkaldsstakken og objekttilstanden i selve chrome-debuggeren.

chrome_debugger

Denne tilgang til debugging af Jest-tests er okay, men ikke særlig brugervenlig, da du skal fortsætte med at skifte fra kodeeditoren til Chrome og omvendt, der forårsager meget friktion. I det kommende afsnit vil vi se måderne til at konfigurere fejlfindingsprogrammet i selve Visual Studio Code-editoren.

# 2) Brug af VS Code's fejlfindingskonfiguration

# 1) Vælg afsnittet Fejl / kør i Visual Studio-koden fra panelet til venstre.

Kør / fejlret

#to) Nu opdaterer vi fejlfindingskonfigurationen til jest-tests. For at gøre det skal du tilføje en ny konfiguration ved at vælge menupunktet.

vælg tilføj konfiguration

# 3) Når indstillingen Tilføj konfiguration er valgt, åbner den filen `launch.json` med standardindholdet i redigeringsruden. Fjern standardindholdet, og kopier indholdet nedenfor for at oprette en fejlfindingskonfiguration til Jest-testene.

{ 'version': '0.2.0', 'configurations': ( { 'name': 'Debug Jest Tests', 'type': 'node', 'request': 'launch', 'runtimeArgs': ( '--inspect-brk', '${workspaceRoot}/node_modules/jest/bin/jest.js', '--runInBand' ), 'console': 'integratedTerminal', 'internalConsoleOptions': 'neverOpen', 'port': 9229 } ) }

# 4) Gem den nyligt tilføjede indholdskonfiguration, der vil blive brugt til fejlfinding af Jest-testene. Hvis du læser igennem konfigurationen omhyggeligt, svarer den til det, vi gjorde, da vi forsøgte at oprette forbindelse til Node-fejlretningen i Chrome Developer-værktøjerne via kommandoen.

--inspect-brk ./node_modules/jest/bin/jest.js --runInBand

Fordelen ved at have konfigureret her er, at testene køres / debugges som en del af selve editoren (i dette tilfælde er det VSCode), og vi behøver ikke oprette forbindelse til nogen ekstern applikation.

# 5) Når fejlretningskonfigurationen er oprettet, kan du nu tilføje breakpoints til testene og udføre ved hjælp af denne RUN-konfiguration. Dette vil sikre, at testen stopper ved pausepunkterne, og du kan fejle værdierne, objekttilstanden ved pausepunktet i den aktuelle testfil.

Breakpoints kan tilføjes ved at klikke tæt på linjenumrene i kodefilerne.

hvordan man får vist en xml-fil

Indstil brudpunkt

# 6) Når brudpunktet er tilføjet, kan vi vælge den kørekonfiguration, som vi tilføjede i trin # 3 for at udføre / debugge testen.

Vælg Kør konfiguration

# 7) Når du vælger / klikker på knappen Kør, skal du kunne se, at udførelsen rammer det brudpunkt, der blev placeret, og du kan få flere detaljer som miljø- / variabelværdier, staksporing osv. Ved brudpunktet.

Kontrolknapperne for breakpoint / code flow kan bruges til at flytte til næste breakpoint eller flytte inde i funktionen for at få flere detaljer.

breakpoint_execution_jest

Video Tutorial Han ERFejlretning

Der er Mocha mod Jasmine

I nedenstående afsnit vil vi sammenligne Jest vs Mocha og Jest vs Jasmine på forskellige parametre og funktionssammenligninger som Snapshot-test, Nem konfiguration og kapaciteter i forskellige rammer.

Parameter Er Mokka Jasmin
Understøttede testtyper Mest brugt til enhedstest.EnhedstestEnhedstest og E2E-test.
Snapshot-test Fuldt understøttet - Specielt brugt til React-komponenter understøtter Jest at tage snapshots af en komponent og bruge den til at sammenligne testoutputtet med den gemte komponentstruktur.
Snapshots er en fantastisk måde at sikre, at brugergrænsefladen ikke ændres uventet.		Ingen hjælpIngen hjælp
Påstande og matchere Brug expect.js-biblioteket til matchere.Support til Node's indbyggede assert-modul og kan også omfatte andre påstandebiblioteker.I indbyggede påstande
Hånende Fuldt indbygget support til Mocks and Stubs i Jest.Ingen indbygget støtte til hån eller stubbing.
Kan bruges med andre biblioteker som Sinon til støtte for Mocking.		Indbygget begrænset support ved hjælp af spyOn.
Kan integreres med andre biblioteker.
Udførelseshastighed 4x
Jest-test er isoleret i deres egen sandkasse. Således kører Jest-tests i det væsentlige parallelt, hvorfor de giver betydelig forbedring i udførelsestider.		x
Understøtter ikke parallel udførelse af tests.		x
Understøtter ikke parallel udførelse af tests.
Konfiguration og opsætning Meget let - nul konfiguration påkrævet.
Tilstand til udførelse af test HovedløsHovedløsHovedløs
Test output og kontekst Genererer rig kontekst efter udførelse - Jest leverer detaljeret testkontekst til at grave dybt ned i, hvad der har forårsaget en fejl og derved sikre let fejlretning.Testoutput er ikke særlig læsbart og gør fejlretning lidt udfordrende.
Fejlretning Support til native Node-debuggere kan også bruges til at debugge inden for redaktører som Visual Studio Code gennem en separat startkonfiguration.Understøtter native Node debugger.Kan bruge karma testløber til at starte tests i Chrome og debug.
Kodedækning Jest har indbygget support til kodedækning.
Dækningskonfiguration kunne specificeres i Jest-konfiguration, og rapporterne kunne genereres med hver testudførelse.		Ingen indbygget support. Giver support til eksterne biblioteker til at generere dækningsrapporter.Samme som mokka
Testform BDD
Alle de tre rammer understøtter tests, der skal skrives som et sæt specifikationer eller specifikationer, der gør dem mere læsbare.		BDDBDD

Konklusion

I denne vejledning lærte vi om de forskellige måder, hvorpå du kan fejle dine Jest-tests inden for Visual Studio-kode eller i Chrome-inspektøren ved hjælp af nodens native debugger.

Vi undersøgte også de almindeligt anvendte konfigurationsindstillinger i Jest-konfigurationsfilen. Jest-konfiguration hjælper med at opnå mange ting som kodedækning, HTML-rapporter, opsætning af mock-opførsel, opsætning af globale variabler osv.

PREV-vejledning | FØRSTE vejledning

Anbefalet læsning