Een inleiding tot Testen In Go

testen is enorm belangrijk in alle software. In staat zijn om de correctheid van uw code te verzekeren en ervoor te zorgen dat eventuele wijzigingen die u maakt niet eindigen breken iets anders in verschillende delen van uw codebase is enorm belangrijk.

door de tijd te nemen om uw go-programma ‘ s adequaat te testen, kunt u zich sneller ontwikkelen met een groter gevoel van vertrouwen dat wat u aan het ontwikkelen bent zal blijven werken wanneer u het in productie brengt.

doelen

aan het einde van deze handleiding hebt u een goed begrip van het testen van basisfuncties en methoden in Go met behulp van het standaard "testing" pakket.

u zult ervaring hebben met het schrijven van tabelgestuurde tests en u zult ook zien hoe u meer uitgebreide uitvoer van uw tests kunt genereren met behulp van de verschillende beschikbare vlaggen.

Video-Tutorial

deze tutorial kan worden gevonden in video-formaat als u dat liever:

Inleiding

in deze tutorial gaan we kijken hoe je testen voor je go-code kunt ontwikkelen en uitvoeren met behulp van het go test Commando.

Go Test Files

Als u eerder go-projecten hebt gezien, hebt u misschien gemerkt dat de meeste, zo niet alle bestanden binnen het project, een FILE_test.go tegenhanger in dezelfde map hebben.

Dit is geen ongeval. Dit zijn de bestanden die alle unit testsvoor het project bevatten en ze testen alle code binnen hun tegenhangers.

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

een eenvoudig testbestand

stel je voor dat we een heel eenvoudig go-programma hadden dat uit één bestand bestond en een calculate() functie had. Deze calculate() functie neemt gewoon 1 nummer in en voegt er 2 aan toe. Leuk en eenvoudig om ons aan de gang te krijgen:

als we dit willen testen, kunnen we een main_test.go bestand aanmaken in de samedirectory en de volgende test schrijven:

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

het uitvoeren van onze Tests

nu we onze eerste go-test hebben gemaakt, is het tijd om dit uit te voeren en te zien of onze Code zich gedraagt zoals we verwachten. We kunnen onze tests uitvoeren door:

$ go test

dit moet dan iets als het volgende uitvoeren:

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

tabel Driven Testing

nu we blij zijn dat één berekening werkt, moeten we kijken naar het verbeteren van het vertrouwen door het toevoegen van een paar extra testcases in onze code. Als we een reeks testcases willen opbouwen die altijd getest worden, kunnen we een array aan tests als volgt berekenen:

hier verklaren we een struct die zowel een input als de verwachte waarde bevat. We herhalen de lijst met tests met onze for _, test := range testscall en check om te zien dat onze functie altijd de verwachte resultaten zal retourneren,ongeacht de invoer.

wanneer we onze test suite nu uitvoeren, zouden we dezelfde uitvoer moeten zien als voorheen:

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

uitgebreide Testoutput

soms wilt u misschien precies zien welke tests worden uitgevoerd en hoe lang de test duurt. Gelukkig is dit beschikbaar als u de -v vlag gebruikt bij het uitvoeren van uw tests als volgt:

u kunt zien dat zowel onze normale test als onze tabel test liep en geslaagd en tookless dan 0.00s uit te voeren.

controle op de dekking van de Test

controle op de dekking van de Test is een maatstaf die ik soms door bedrijven heb zien misbruiken. Deze ondernemingen stellen doelstellingen vast voor al hun systemen, zoals “de codebase moet voor ten minste 75% door tests worden bestreken”.

maar dit soort doelen kan leiden tot slecht gedrag en ontwikkeling teams “gaming”het systeem om te proberen en raken deze doelen. Ik heb gezien dat mensen in sommige teamspend dagen schrijven eenheid tests die basis getters en setters test in talen zoals Java.

testen is enorm belangrijk, maar je moet pragmatisch zijn over hoe je je systemen test, zodat de tests die je schrijft je de meeste waarde geven.

de dagen besteed aan het schrijven van tests om onbelangrijke delen van uw codebase te bestrijken, hadden beter kunnen worden besteed aan het schrijven van testcases rond de kritieke bedrijfslogica die binnen uw systemen is opgenomen, zodat er meer edgecases worden bestreken.

met de-cover vlag

met het belangrijke deel uit de weg, laten we eens kijken hoe u de test dekking van uw systeem kunt controleren met behulp van het go test Commando:

binnen dezelfde map als uw main.go en uw main_test.go bestanden, voer het volgende uit:

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

u zult zien dat u 66.7% van uw totale Go-code hebt gedekt door testcases.

het visualiseren van dekking

hoewel deze waarde 66.7% ons kan vertellen hoeveel van onze code we hebben getest, toont het ons niet precies welke codepaden we hebben of niet hebben getest.

hier komen de go test en de go tool cover om ons te helpen dit specifieke probleem op te lossen.

we kunnen het go test gereedschap gebruiken om een coverprofile te genereren die vervolgens kan worden omgezet naar een HTML-visualisatie met behulp van het go tool cover Commando:

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

u kunt dan dit gegenereerde coverage.out bestand nemen en het gebruiken om een HTML-pagina te genereren die precies laat zien welke regels op deze manier zijn bedekt:

$ go tool cover -html=coverage.out

dit zal het openen van een pagina in uw browser van keuze die er een beetje als dit zal uitzien:

zoals u kunt zien, is het grootste deel van de code binnen onze Calculate functie testen en features Green dekking. Terwijl het print statement in uw main functie Red is omdat dit niet door tests is behandeld.

conclusie

hopelijk vond u deze tutorial nuttig! Als u verdere hulp nodig hebt, aarzel dan niet om me te laten weten in de commentaren hieronder.