Une introduction aux tests dans Go

Les tests sont extrêmement importants dans tous les logiciels. Être en mesure de garantir la correctivité de votre code et de s’assurer que toutes les modifications que vous apportez ne finissent pas par casser quoi que ce soit d’autre dans différentes parties de votre base de code est extrêmement important.

En prenant le temps de tester adéquatement vos programmes go, vous vous permettez de vous développer plus rapidement avec un plus grand sentiment de confiance que ce que vous développez continuera de fonctionner lorsque vous le mettrez en production.

Objectifs

À la fin de ce tutoriel, vous comprendrez bien tester les fonctions de base et les méthodes de Go en utilisant le package standard "testing".

Vous aurez eu de l’expérience dans l’écriture de tests pilotés par table et vous verrez également comment générer des résultats plus détaillés à partir de vos tests en utilisant les différents indicateurs disponibles.

Tutoriel vidéo

Ce tutoriel peut être trouvé au format vidéo si vous préférez:

Introduction

Dans ce tutoriel, nous allons voir comment vous pouvez développer et exécuter des tests pour votre code go en utilisant la commande go test.

Fichiers de test Go

Si vous avez déjà vu des projets go, vous avez peut-être remarqué que la plupart, sinon tous les fichiers du projet, comportent une contrepartie FILE_test.go dans le même répertoire.

Ce n’est pas un accident. Ce sont les fichiers qui contiennent tous les tests unitaires pour le projet et ils testent tout le code dans leurs homologues.

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

Un fichier de test simple

Imaginez que nous avions un programme go très simple composé d’un seul fichier et doté d’une fonction calculate(). Cette fonction calculate() prend simplement 1number et en ajoute 2. Agréable et simple pour nous mettre en marche:

Si nous voulions tester cela, nous pourrions créer un fichier main_test.go dans le même répertoire et écrire le test suivant:

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

Exécution de nos Tests

Maintenant que nous avons créé notre premier test go, il est temps de l’exécuter et de voir si ourcode se comporte comme nous l’attendons. Nous pouvons exécuter nos tests en exécutant:

$ go test

Cela devrait alors produire quelque chose de similaire à ce qui suit:

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

Tests pilotés par table

Maintenant que nous sommes heureux qu’un calcul fonctionne, nous devrions chercher à améliorer la confiance en ajoutant quelques cas de test supplémentaires dans notre code. Si nous voulons généralement construire une série de cas de test qui sont toujours testés, nous pouvons générer un array de tests comme ceci:

Ici, nous déclarons une structure qui contient à la fois une entrée et la valeur attendue. Nous parcourons ensuite la liste des tests avec notre appel for _, test := range tests et vérifions que notre fonction retournera toujours les résultats attendus, quelle que soit l’entrée.

Lorsque nous exécutons notre suite de tests maintenant, nous devrions voir la même sortie qu’auparavant:

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

Sortie de test détaillée

Parfois, vous voudrez peut-être voir exactement quels tests sont en cours d’exécution et combien de temps ils ont duré. Heureusement, cela est disponible si vous utilisez l’indicateur -v lors de l’exécution de yourtests comme ceci:

Vous pouvez voir que notre test normal et notre test de table ont couru et réussi et ont pris moins que 0.00s pour s’exécuter.

Vérification de la couverture des tests

La couverture des tests est une mesure que j’ai parfois vue abusée par les entreprises. Ces entreprises fixent des objectifs sur tous leurs systèmes tels que « la base de code doit être couverte à au moins 75% par des tests ».

Mais ce genre de cibles peut conduire à de mauvais comportements et les équipes de développement « jouent » sur le système afin d’essayer d’atteindre ces cibles. J’ai vu des gens dans certaines équipes passer des jours à écrire des tests unitaires qui testent les getters et les setters de base dans des langues telles que Java.

Les tests sont extrêmement importants, mais vous devez être pragmatique sur la façon dont vous testez vos systèmes afin que les tests que vous écrivez vous apportent le plus de valeur.

Les jours passés à écrire des tests pour couvrir des parties sans importance de votre base de code pourraient avoir été mieux passés à écrire des cas de test autour de la logique métier critique de vos systèmes et à s’assurer que davantage de cas périphériques sont couverts.

En utilisant l’indicateur -cover

Avec la partie importante à l’écart, regardons comment vous pouvez vérifier la couverture du test de votre système en utilisant la commande go test:

Dans le même répertoire que vos fichiers main.go et vos fichiers main_test.go, exécutez les éléments suivants:

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

Vous verrez que vous avez 66.7% de votre code Go total couvert par testcases.

Visualisation de la couverture

Bien que cette valeur 66.7% puisse nous indiquer la quantité de code que nous avons testée, elle ne nous montre pas exactement quels chemins de code nous avons ou n’avons pas testés.

C’est là que les go test et les go tool cover interviennent pour nous aider à résoudre ce problème particulier.

Nous pouvons utiliser l’outil go test pour générer un coverprofile qui peut ensuite être converti en une visualisation HTML à l’aide de la commande go tool cover :

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

Vous pouvez ensuite prendre ce fichier coverage.out généré et l’utiliser pour générer une page HTML qui montre exactement quelles lignes ont été couvertes comme ceci:

$ go tool cover -html=coverage.out

Cela ouvrira une page dans votre navigateur de choix qui ressemblera un peu à ceci:

Comme vous pouvez le voir, la majeure partie du code de notre fonction Calculate teste la couverture des caractéristiques Green. Alors que l’instruction print dans votre fonction main est Red car cela n’a pas été couvert par des tests.

Conclusion

J’espère que vous avez trouvé ce tutoriel utile! Si vous avez besoin d’aide supplémentaire, n’hésitez pas à me le faire savoir dans la section commentaires ci-dessous.