En Introduksjon Til Testing I Go

Testing er enormt viktig i all programvare. Å kunne sikre at koden din er riktig og at eventuelle endringer du gjør, ikke ender opp med å bryte noe annet i ulike deler av kodebasen din, er enormt viktig.

ved å ta deg tid til å tilstrekkelig teste dine go-programmer, tillater du deg selv å utvikle seg raskere med større følelse av selvtillit at det du utvikler vil fortsette å fungere når du slipper det til produksjon.

Mål

ved slutten av denne opplæringen vil du ha en god forståelse av å teste grunnleggende funksjonerog metoder I Go ved hjelp av standard "testing" pakken.

Du vil ha hatt erfaring med å skrive borddrevne tester, og du vil også se hvordan du genererer mer verbose utdata fra testene dine ved hjelp av de forskjellige flagstilgjengelige.

Video Tutorial

denne opplæringen kan bli funnet i videoformat hvis du foretrekker:

Innledning

i denne opplæringen skal vi se på hvordan du kan utvikle og kjøre tester foryour go-koden ved hjelp av kommandoen go test.

Gå Testfiler

hvis du har sett noen go-prosjekter før, har du kanskje lagt merke til at de fleste, hvis ikke alle filene i prosjektet, har en FILE_test.go motpart i samme katalog.

Dette er ikke en ulykke. Dette er filene som inneholder alle enhetstestene for prosjektet, og de tester all koden i sine kolleger.

myproject/- calc.go- calc_test.go- main.go- main_test.go

En Enkel Testfil

Tenk deg at vi hadde et veldig enkelt go-program som besto av en fil og kjennetegnet en calculate() – funksjon. Denne calculate() – funksjonen tar bare inn 1nummer og legger til 2 til det. Fin og enkel å få oss i gang:

hvis vi ønsket å teste dette, kunne vi lage en main_test.go fil i samedirectory og skrive følgende test:

package mainimport ( "testing")func TestCalculate(t *testing.T) { if Calculate(2) != 4 { t.Error("Expected 2 + 2 to equal 4") }}

Kjører Våre Tester

Nå som vi har laget vår første go-test, er det på tide å kjøre dette og se om koden vår oppfører seg slik vi forventer. Vi kan utføre våre tester ved å kjøre:

$ go test

Dette skal da sende ut noe som ligner på følgende:

PASSok _/Users/elliot/Documents/Projects/tutorials/golang/go-testing-tutorial 0.007s

Tabelldrevet Testing

Nå som vi er glade for at en beregning fungerer, bør vi se for å forbedre selvtillit ved å legge til noen ekstra testtilfeller i koden vår. Hvis vi vilgradvis bygge opp en serie testtilfeller som alltid testes, kan vi gjennomsnittlig en array av tester som så:

her erklærer vi en struktur som inneholder både en inngang og forventet verdi. Vi itererer gjennom listen over tester med vår for _, test := range testsring og sjekk for å se at vår funksjon alltid vil returnere de forventede resultatene, uavhengig av innspill.

når vi kjører vår testpakke nå, bør vi se samme utgang som før:

PASSok _/Users/elliot/Documents/Projects/tutorials/golang/go-testing-tutorial 0.007s

Detaljert Testutgang

noen ganger kan du ønske å se nøyaktig hvilke tester som kjører Og hvor lenge de tok. Heldigvis er dette tilgjengelig hvis du bruker flagget -v når du kjører yourtests slik:

Du kan se at både vår normale test og vår tabelltest kjørte og passerte og tok mindre enn 0.00s å utføre.

Kontroll Av Testdekning

Testdekning er en metrisk som jeg har sett misbrukt til tider av selskaper. Disse selskapene setter mål på alle sine systemer som «kodebasen må være minst 75% dekket av tester».

men disse slags mål kan føre til dårlig oppførsel og utviklingsteam «gaming»systemet for å prøve og treffe disse målene. Jeg har sett folk i noen lagtilbringe dager skrive enhetstester som tester grunnleggende getters og settere på språk som Java.

Testing er enormt viktig, men Du må være pragmatisk om hvordan du tester systemene dine slik at testene du skriver gir deg mest mulig verdi.

dagene som brukes til å skrive tester for å dekke ubetydelige deler av kodebasen, kunne vært bedre brukt til å skrive testtilfeller rundt den kritiske forretningslogikken fanget i systemene dine og sikre at flere kantsaker er dekket.

Bruke-cover-flagget

Med den viktige delen ut av veien, la oss se på hvordan du kan sjekketestdekning av systemet ditt ved hjelp av kommandoen go test:

I samme katalog som din main.go og dine main_test.go filer, kjørfølgende:

PASScoverage: 66.7% of statementsok github.com/TutorialEdge/an-intro-to-testing-in-go 0.006s

Du vil se at du har 66.7% av din totale Go-kode dekket av testtilfeller.

Visualisere Dekning

mens denne 66.7% verdien kan fortelle oss hvor mye av koden vi har testet,viser den oss ikke nøyaktig hvilke kodebaner vi har eller ikke har testet.

dette er hvor go test og go tool cover kommer inn for å hjelpe oss med å løse dette spesielle problemet.

vi kan bruke verktøyet go test til å generere en coverprofile som deretter kan konverteres TIL EN HTML-visualisering ved hjelp av kommandoen go tool cover:

PASScoverage: 66.7% of statementsok github.com/TutorialEdge/an-intro-to-testing-in-go 0.008s

du kan da ta denne genererte coverage.out filen og bruke den til å generereen HTML-side som viser nøyaktig hvilke linjer som er dekket slik:

$ go tool cover -html=coverage.out

Dette vil åpne opp en side i nettleseren av valget som vil se littlesomething som dette:

som du kan se, er det meste av koden i vår Calculate funksjon testing andfeatures Green dekning. Mens utskriftsoppgaven i main – funksjonen er Red, da dette ikke er dekket av tester.

Konklusjon

Forhåpentligvis fant du denne opplæringen nyttig! Hvis du trenger ytterligere hjelp, vær så snill å gi meg beskjed i kommentarfeltet nedenfor.