Conventions de codage Go

Introduction aux conventions de codage Go : Viser la lisibilité et la cohérence

En Go, la lisibilité et la cohérence du code sont des valeurs primordiales, au même titre que la performance et l'efficacité. Go a été conçu avec une forte emphase sur la simplicité et la clarté du code, et la communauté Go attache une grande importance au respect des conventions de codage, qui visent à uniformiser le style du code Go, à faciliter sa lecture et sa compréhension, et à promouvoir la collaboration et la maintenabilité des projets Go.

Les conventions de codage Go ne sont pas seulement des règles arbitraires de style, mais plutôt un ensemble de bonnes pratiques et de recommandations qui découlent de la philosophie et des principes de conception du langage Go. Respecter les conventions de codage Go permet d'écrire du code idiomatique, élégant, facile à lire, et cohérent avec le reste de l'écosystème Go, facilitant ainsi la collaboration, la revue de code, et la maintenance à long terme.

Ce chapitre vous propose un guide complet sur les conventions de codage Go. Nous allons explorer en détail les conventions de formatage du code (avec l'outil gofmt), les styles de nommage (noms de packages, de fichiers, de fonctions, de variables, de types, etc.), les bonnes pratiques pour les commentaires et la documentation, les conventions spécifiques à la gestion des erreurs, aux tests, et à d'autres aspects du code Go. L'objectif est de vous fournir un guide de référence pratique et exhaustif pour maîtriser les conventions de codage Go et écrire du code Go de qualité professionnelle, lisible, cohérent, et conforme aux standards de la communauté Go.

Formatage automatique du code avec gofmt : Laisser l'outil faire le travail

En Go, le formatage du code est largement standardisé et automatisé grâce à l'outil gofmt (Go format). gofmt est un outil de formatage de code intégré à la chaîne d'outils Go, qui reformatte automatiquement votre code Go pour qu'il respecte un style de code uniforme et prédéterminé, conforme aux conventions de style de la communauté Go.

Principe et avantages de gofmt :

• Formatage automatique et standardisé : gofmt formate automatiquement votre code Go, en appliquant un ensemble de règles de style prédéfinies (indentation, espacement, alignement, sauts de ligne, etc.). Le formatage produit par gofmt est standardisé et cohérent, garantissant que le code Go, quel que soit son auteur, respecte un style uniforme et prévisible.
• Lisibilité et cohérence du code : Le formatage uniforme imposé par gofmt améliore considérablement la lisibilité et la cohérence du code Go. Un code bien formaté est plus facile à lire, à comprendre, à parcourir, et à maintenir. La cohérence du style du code, à travers tous les projets Go, facilite la collaboration et la revue de code.
• Evite les débats de style et les guerres de formatage : gofmt tranche les débats subjectifs sur le style de code. En utilisant gofmt, vous n'avez plus à vous soucier des préférences individuelles de formatage ou des guerres de style au sein d'une équipe. gofmt impose un style de code unique et objectif, permettant aux développeurs de se concentrer sur la logique du code plutôt que sur son formatage.
• Outil intégré et facile à utiliser : gofmt est intégré à la chaîne d'outils Go et est extrêmement facile à utiliser. Il suffit d'exécuter la commande go fmt dans le répertoire de votre projet Go pour formater automatiquement tous les fichiers .go du package courant (ou go fmt ./... pour formater récursivement tous les packages du répertoire courant et des sous-répertoires). De nombreux éditeurs de code et IDE Go intègrent également gofmt et permettent de formater automatiquement le code à la sauvegarde ou à la demande.

Utilisation de gofmt : Commande et intégration dans l'éditeur

Commande go fmt : Formater le code en ligne de commande

Pour formater votre code Go avec gofmt en ligne de commande, naviguez jusqu'au répertoire de votre projet Go dans le terminal et exécutez la commande :

go fmt ./... # Formater tous les fichiers .go du répertoire courant et des sous-répertoires
go fmt monfichier.go # Formater un fichier .go spécifique

go fmt reformatte directement les fichiers sources (il ne modifie pas la sortie standard). Il est recommandé d'exécuter go fmt régulièrement (par exemple, avant de commiter des changements dans Git) pour maintenir un code toujours bien formaté.

Intégration de gofmt dans les éditeurs de code et IDE :

La plupart des éditeurs de code et IDE Go (VS Code Go extension, GoLand, Vim Go plugin, Emacs Go mode, etc.) intègrent gofmt et permettent de formater automatiquement le code à la sauvegarde ou à la demande (via une commande ou un raccourci clavier). L'intégration de gofmt dans votre éditeur de code est fortement recommandée, car elle permet de maintenir un code toujours bien formaté en temps réel, au fur et à mesure de votre développement, sans avoir à exécuter manuellement la commande go fmt en ligne de commande.

Conventions de formatage imposées par gofmt : Exemples

gofmt applique un ensemble de règles de formatage prédéfinies, couvrant différents aspects du style de code Go. Voici quelques exemples de conventions de formatage imposées par gofmt :

• Indentation : gofmt utilise l'indentation par tabulation (tab characters) pour indenter le code (par défaut, 8 espaces par tabulation dans la plupart des éditeurs, mais gofmt utilise des tabulations réelles).
• Espacement : gofmt gère automatiquement l'espacement autour des opérateurs, des mots-clés, des accolades, des parenthèses, des virgules, etc., pour améliorer la lisibilité du code. Par exemple, gofmt ajoute des espaces autour des opérateurs binaires (+, -, *, /, ==, !=, etc.), après les virgules dans les listes d'arguments ou de paramètres, après les deux-points dans les maps et les structs littéraux, etc.
• Alignement : gofmt aligne automatiquement certaines constructions de code, comme les affectations multiples, les déclarations de variables, les champs de structs, les éléments de tableaux ou de slices littéraux, pour améliorer la lisibilité du code en colonnes.
• Sauts de ligne : gofmt gère automatiquement les sauts de ligne pour les longues lignes de code, les listes d'arguments ou de paramètres, les structs littéraux, les conditions if, les boucles for, les blocs switch, etc., en appliquant des règles de mise en page pour rendre le code plus lisible et moins dense visuellement.
• Ordre des imports : gofmt trie automatiquement les imports par ordre alphabétique et regroupe les imports par package standard et packages tiers, améliorant l'organisation et la lisibilité des déclarations d'import.
• Simplification des expressions : gofmt simplifie automatiquement certaines expressions de code pour les rendre plus concises et idiomatiques. Par exemple, gofmt remplace automatiquement x == true par x, x == false par !x, etc.

En utilisant gofmt systématiquement, vous vous assurez que votre code Go est toujours bien formaté, lisible, cohérent, et conforme aux conventions de style de la communauté Go, facilitant ainsi la collaboration, la revue de code, et la maintenance à long terme.

Style de nommage : Clarté et conventions pour les identificateurs

Le style de nommage (naming conventions) est un aspect essentiel des conventions de codage Go. Choisir des noms clairs, descriptifs, concis, et cohérents pour les identificateurs (packages, fichiers, fonctions, types, variables, constantes, etc.) est crucial pour la lisibilité, la compréhension, et la maintenabilité du code Go.

Conventions de nommage Go générales :

• Clarté et descriptivité : Choisissez des noms qui sont clairs, descriptifs, et qui indiquent clairement le rôle, la fonction, ou la signification de l'identificateur. Un bon nom doit être facile à comprendre et à interpréter par les autres développeurs (et par vous-même dans le futur). Privilégiez les noms explicites et non ambigus.
• Concision : Tout en étant descriptifs, essayez de choisir des noms concis et pas trop longs. Evitez les noms excessivement longs ou verbeux, qui peuvent alourdir le code et nuire à la lisibilité. Recherchez un équilibre entre la clarté et la concision.
• Cohérence : Adoptez un style de nommage cohérent dans l'ensemble de votre projet Go. Utilisez les mêmes conventions de nommage pour les identificateurs similaires, et respectez les conventions de nommage de la communauté Go (voir ci-dessous). La cohérence du style de nommage facilite la lecture et la compréhension du code et réduit la confusion.
• Utiliser l'anglais (généralement) : Par convention, la plupart des projets Go utilisent l'anglais pour les noms d'identificateurs, en particulier pour les packages, les fonctions exportées, les types exportés, et les variables publiques. L'utilisation de l'anglais facilite la collaboration avec la communauté Go internationale et rend votre code plus accessible à un public plus large. Pour les projets internes ou les projets très spécifiques à une langue locale, l'utilisation d'une autre langue peut être acceptable, mais l'anglais reste la convention dominante dans l'écosystème Go.

Conventions de nommage Go spécifiques par type d'identificateur :

• Noms de packages : Les noms de packages doivent être :
  • Courts et concis : Généralement un seul mot (ou deux mots au maximum).
  • En minuscule : Toujours en minuscule.
  • Singulier (généralement) : Préférez le singulier, sauf si le pluriel est plus naturel (par exemple, strings, fmt).
  • Descriptifs : Décrire clairement le but ou le domaine du package.
  • Exemples : fmt, http, sync, io, os, strings, time, net, errors, context, encoding/json, database/sql.
• Noms de fichiers : Les noms de fichiers doivent être :
  • En minuscule : Toujours en minuscule.
  • Snake case (séparés par des underscores _) : Utilisez la casse snake_case pour séparer les mots (par exemple, mon_fichier.go, utilisateur_service.go).
  • Descriptifs : Décrire le contenu principal du fichier (par exemple, http_handlers.go, database_models.go, calculatrice_test.go).
• Noms de fonctions et de méthodes : Les noms de fonctions et de méthodes doivent être :
  • PascalCase (CamelCase avec première lettre majuscule) : Utilisez la casse PascalCase (ou CamelCase avec première lettre majuscule) pour les noms de fonctions et de méthodes exportées (publiques, visibles depuis d'autres packages). Par exemple, FonctionExportee, MethodeExportee, OuvrirFichier, CalculerSomme.
  • camelCase (CamelCase avec première lettre minuscule) : Utilisez la casse camelCase (ou CamelCase avec première lettre minuscule) pour les noms de fonctions et de méthodes non exportées (privées au package, visibles uniquement à l'intérieur du package). Par exemple, fonctionNonExportee, methodeNonExportee, calculerMoyenne, validerDonnees.
  • Verbes (généralement) : Les noms de fonctions et de méthodes sont souvent des verbes ou des phrases verbales qui décrivent l'action effectuée par la fonction ou la méthode (par exemple, OuvrirFichier, CalculerSomme, EnvoyerEmail, GetUtilisateur, EstValide).
• Noms de types (structs, interfaces, types dérivés) : Les noms de types doivent être :
  • PascalCase (CamelCase avec première lettre majuscule) : Utilisez la casse PascalCase pour les noms de types (structs, interfaces, types dérivés). Par exemple, Utilisateur, AdresseLivraison, ServiceEmail, Calculatrice, Operation, NombreEntier.
  • Noms courts et descriptifs : Choisissez des noms de types courts, concis, et descriptifs qui indiquent clairement le rôle ou la nature du type.
  • Interfaces : suffixe -er (souvent) : Par convention, les noms d'interfaces se terminent souvent par le suffixe -er (comme Reader, Writer, Stringer, Logger, Handler, Exporter, Validator), pour indiquer qu'il s'agit d'interfaces qui définissent un comportement ou un contrat. Ce n'est pas une règle stricte, mais une convention courante dans l'écosystème Go.
• Noms de variables et de constantes : Les noms de variables et de constantes doivent être :
  • camelCase (CamelCase avec première lettre minuscule) : Utilisez la casse camelCase pour les noms de variables et de constantes. Par exemple, nomUtilisateur, ageUtilisateur, nombreDeProduits, cheminFichier, erreurConnexion, maxConnections, defaultTimeout.
  • Noms courts et contextuels (portée réduite) : Pour les variables de portée réduite (variables locales, variables de boucle, variables courtes), utilisez des noms courts et concis (parfois même des noms d'une seule lettre comme i, j, k pour les compteurs de boucle, r pour un reader, w pour un writer, c pour un context, etc.). Le contexte local de la variable doit suffire à comprendre son rôle et sa signification.
  • Noms plus longs et descriptifs (portée plus large) : Pour les variables de portée plus large (variables de package, variables globales, champs de structs), utilisez des noms plus longs et plus descriptifs, pour faciliter leur compréhension et leur utilisation dans différentes parties du code.
  • Constantes : PascalCase ou UPPER_SNAKE_CASE : Pour les constantes exportées (constantes publiques), utilisez la casse PascalCase (comme pour les types exportés, par exemple, ErrFichierNonTrouve, DefaultTimeout). Pour les constantes non exportées (constantes privées), utilisez la casse camelCase (comme pour les variables non exportées, par exemple, defaultBufferSize, maxRetries) ou UPPER_SNAKE_CASE (majuscules séparées par des underscores, comme MAX_CONNECTIONS, BUFFER_SIZE, pour les constantes globales ou les constantes de package).
  • Variables booléennes : Noms affirmatifs (souvent) : Pour les variables de type bool (booléennes), utilisez souvent des noms affirmatifs qui indiquent un état vrai (estValide, estConnecte, aErreur, isActive, isEnabled, etc.), facilitant la lecture des conditions if et des expressions booléennes (if estValide { ... }, if !estConnecte { ... }).

En respectant ces conventions de nommage Go, vous écrirez du code Go lisible, cohérent, facile à comprendre, et conforme aux standards de la communauté Go, facilitant ainsi la collaboration, la revue de code, et la maintenance à long terme.

Commentaires et documentation : Rendre le code auto-documenté et compréhensible

Les commentaires et la documentation sont des éléments essentiels d'un code Go de qualité. Un code Go bien commenté et bien documenté est plus facile à comprendre, à maintenir, à utiliser, et à partager avec d'autres développeurs (ou avec vous-même dans le futur). Go encourage fortement l'écriture de code auto-documenté, c'est-à-dire un code qui est suffisamment clair et expressif en lui-même, mais qui est également accompagné de commentaires et d'une documentation de qualité pour expliquer les choix de conception, les fonctionnalités, et l'utilisation du code.

Types de commentaires en Go :

Go supporte deux types de commentaires :

• Commentaires de ligne (//) : Les commentaires de ligne commencent par // et s'étendent jusqu'à la fin de la ligne. Ils sont utilisés pour les commentaires courts, les explications locales, les notes de code, et les commentaires temporaires (pour désactiver temporairement une ligne de code, par exemple).
• Commentaires de bloc (/* ... */) : Les commentaires de bloc commencent par /* et se terminent par */. Ils peuvent s'étendre sur plusieurs lignes et sont utilisés pour les commentaires plus longs, les commentaires de documentation (voir section suivante), les notes de conception, les explications de blocs de code complexes, et les commentaires multi-lignes.

Commentaires de documentation (Doc Comments) : Documentation de l'API publique

Les commentaires de documentation (doc comments), également appelés Go doc comments, sont un type spécial de commentaires en Go utilisés pour documenter l'API publique de vos packages, fonctions, types, variables, et constantes exportées (celles commençant par une majuscule). Les commentaires de documentation sont écrits juste avant la déclaration de l'élément de code à documenter, et ils sont formatés de manière spécifique pour être extraits et affichés par l'outil go doc (l'outil de documentation de Go).

Syntaxe des commentaires de documentation (Doc Comments) :

• Commentaires de package : Un commentaire de package est un commentaire de documentation placé juste après la déclaration package nomdupackage au début d'un fichier .go. Il doit commencer par // Package nomdupackage (ou /* Package nomdupackage ... */ pour un commentaire de bloc) et fournir une description générale du package, de son but, de ses fonctionnalités principales, et de son utilisation. Il doit être concis et informatif, et servir d'introduction à la documentation du package.
• Commentaires de fonctions, types, variables, constantes exportées : Pour documenter une fonction, un type, une variable, ou une constante exportée, placez un commentaire de documentation juste avant sa déclaration. Le commentaire de documentation doit commencer par le nom de l'élément de code (fonction, type, variable, constante) et fournir une description détaillée de son rôle, de son fonctionnement, de ses arguments (pour les fonctions et méthodes), de ses valeurs de retour (pour les fonctions et méthodes), de ses cas d'utilisation, de ses limitations, et de tout autre information pertinente pour les utilisateurs de l'API publique. Utilisez des phrases complètes, une grammaire correcte, et un style clair et concis pour les commentaires de documentation.

Exemple de commentaires de documentation (Doc Comments) :

// Package calculatrice fournit des fonctions pour effectuer des opérations mathématiques de base.
//
// Ce package inclut des fonctions pour l'addition, la soustraction, la multiplication et la division d'entiers.
package calculatrice

// Additionner additionne deux entiers et retourne leur somme.
//
// Exemple d'utilisation :
//
//  somme := calculatrice.Additionner(5, 3) // somme vaut 8
//
func Additionner(a int, b int) int {
    return a + b
}

// Diviser divise deux entiers et retourne le quotient et le reste.
//
// La fonction Diviser panique si le diviseur est zéro.
//
// Paramètres :
//   dividende : Le nombre à diviser.
//   diviseur  : Le diviseur (ne doit pas être zéro).
//
// Valeurs de retour :
//   quotient : Le quotient de la division.
//   reste    : Le reste de la division.
//
// Erreurs :
//   panic    : Panique si le diviseur est zéro.
//
func Diviser(dividende int, diviseur int) (quotient int, reste int) {
    if diviseur == 0 {
        panic("division par zéro")
    }
    return dividende / diviseur, dividende % diviseur
}

Génération de documentation Go avec go doc et outils web (pkg.go.dev) :

L'outil go doc (intégré à la chaîne d'outils Go) permet d'extraire et d'afficher la documentation de votre code Go à partir des commentaires de documentation (Doc Comments). Vous pouvez utiliser go doc en ligne de commande pour afficher la documentation dans le terminal (go doc nomdupackage, go doc nomdupackage.NomFonction, go doc nomdupackage.NomType, etc.) ou générer une documentation HTML (go doc -html nomdupackage).

Le site web [pkg.go.dev](https://pkg.go.dev/) (Go Packages) utilise également les commentaires de documentation Go pour afficher la documentation de tous les packages Go publics (bibliothèque standard, packages tiers sur GitHub, etc.). Votre documentation Go, si elle est écrite correctement, sera automatiquement visible sur [pkg.go.dev](https://pkg.go.dev/) une fois que vous aurez publié votre code Go en tant que package public (module Go).

Des commentaires et une documentation de qualité sont essentiels pour rendre votre code Go auto-documenté, facile à comprendre, à utiliser, et à maintenir, et pour faciliter la collaboration et le partage de votre code avec la communauté Go.

Gestion des erreurs : Conventions et style idiomatique

La gestion des erreurs est un aspect fondamental du code Go idiomatique, et certaines conventions et bonnes pratiques sont largement adoptées par la communauté Go pour la gestion des erreurs, afin d'assurer la robustesse, la lisibilité, et la cohérence du code en matière de gestion des erreurs.

Conventions de gestion des erreurs en Go :

• Vérification systématique des erreurs : if err != nil : Comme nous l'avons souligné dans le chapitre 10, la vérification systématique des erreurs est la règle d'or en Go. Vérifiez toujours la valeur error retournée par une fonction qui peut potentiellement échouer avec if err != nil, et traitez l'erreur explicitement de manière appropriée. Ne jamais ignorer les erreurs.
• Retourner explicitement les erreurs : return error : Les fonctions qui peuvent potentiellement échouer doivent retourner explicitement une valeur de type error comme dernière valeur de retour, en utilisant le pattern idiomatique func FonctionRisquée() (resultat, error). En cas de succès, retournez nil comme valeur error. En cas d'erreur, retournez une valeur error non-nil décrivant l'erreur.
• Error Wrapping avec fmt.Errorf et %w : Lors de la propagation des erreurs à travers les fonctions, utilisez l'error wrapping avec fmt.Errorf et le verbe %w pour enrichir les erreurs avec du contexte (nom de la fonction, opération en cours, etc.) et préserver la chaîne d'erreurs originale. L'error wrapping facilite le débogage et la compréhension du flux des erreurs.
• Types d'erreurs personnalisés pour les erreurs riches en informations : Créez des types d'erreurs personnalisés (structs, types dérivés) pour les erreurs qui nécessitent de transporter des informations structurées au-delà d'un simple message textuel (codes d'erreur, catégories, détails, etc.). Les types d'erreurs personnalisés permettent un traitement plus précis et différencié des erreurs.
• Gestion des erreurs au niveau approprié : Gérez les erreurs localement lorsque c'est possible et pertinent (par exemple, en tentant une action de récupération, en utilisant une valeur par défaut, ou en logguant l'erreur). Propager les erreurs aux fonctions appelantes uniquement lorsque la fonction courante n'est pas en mesure de gérer l'erreur de manière significative, ou lorsque la responsabilité de la gestion de l'erreur incombe à un niveau supérieur de l'application.
• Messages d'erreur clairs et informatifs : Ecrivez des messages d'erreur clairs, concis, et informatifs, qui décrivent précisément la nature de l'erreur, le contexte dans lequel elle s'est produite, et éventuellement des indications sur la manière de la résoudre ou de la corriger. Evitez les messages d'erreur vagues, obscurs, ou trop techniques, qui ne sont pas utiles pour le débogage ou la gestion des erreurs.
• Logging des erreurs (stratégiquement) : Utilisez le logging pour enregistrer les erreurs de manière stratégique dans votre application, en particulier les erreurs qui sont propagées aux niveaux supérieurs de l'application ou qui nécessitent une intervention humaine (opérateurs système, administrateurs, développeurs). Logguez les erreurs avec un niveau de log approprié (erreur, warning, info, debug, etc.) et incluez des informations contextuelles pertinentes (horodatage, identifiant de requête, informations utilisateur, pile d'appels, etc.) dans les logs pour faciliter le débogage et le suivi des erreurs.
• Eviter de paniquer (panic) pour la gestion des erreurs courantes : Réservez l'utilisation de panic aux cas d'erreurs véritablement exceptionnelles et irrécupérables qui indiquent un bug dans votre code ou une condition d'erreur grave qui ne peut pas être gérée de manière normale (erreurs de logique interne, accès invalides à la mémoire, erreurs de configuration critiques, etc.). Pour la gestion des erreurs courantes et prévisibles (fichiers non trouvés, erreurs réseau, erreurs de validation, etc.), utilisez le retour d'erreurs explicites (avec le type error) et laissez le code appelant gérer ces erreurs de manière contrôlée.

En respectant ces conventions de gestion des erreurs en Go, vous écrirez du code Go robuste, fiable, facile à déboguer, et conforme aux standards de la communauté Go en matière de gestion des erreurs.

Tests : Ecrire des tests unitaires clairs et exhaustifs

L'écriture de tests unitaires est une partie intégrante et essentielle du développement Go. Ecrire des tests unitaires clairs, exhaustifs, maintenables, et performants est une compétence fondamentale pour tout développeur Go professionnel. Voici quelques conventions et bonnes pratiques à suivre pour l'écriture de tests unitaires Go de qualité :

Conventions pour l'écriture de tests unitaires en Go :

• Tests unitaires pour chaque package et chaque fonctionnalité : Ecrivez des tests unitaires pour chaque package et chaque fonctionnalité de votre code Go. Visez une couverture de code raisonnablement élevée (80-90% ou plus) pour vos tests unitaires, en particulier pour les parties critiques et complexes de votre code (logique métier, algorithmes, gestion des erreurs, etc.). Les tests unitaires doivent être considérés comme une partie intégrante du code Go, et non comme une activité optionnelle ou secondaire.
• Tests unitaires petits, rapides, et isolés : Ecrivez des tests unitaires qui soient petits, rapides à exécuter, et isolés des dépendances externes. Un test unitaire doit se concentrer sur la validation d'une unité de code (fonction, méthode, package) de manière isolée, sans dépendre de l'état du système, de bases de données réelles, de services externes, ou d'autres facteurs externes qui pourraient rendre les tests lents, non déterministes, ou difficiles à mettre en place. Utilisez le mocking et le stubbing (chapitre 19) pour isoler les dépendances externes lors des tests unitaires.
• Tests unitaires clairs et lisibles : Ecrivez des tests unitaires qui soient clairs, lisibles, et faciles à comprendre. Utilisez des noms de fonctions de test descriptifs (TestFonctionATester, BenchmarkFonctionABenchmarker), des noms de cas de test clairs (dans les table-driven tests), des messages d'erreur informatifs (avec t.Errorf et t.Fatalf), et une structure de code de test organisée et cohérente. Des tests unitaires clairs et lisibles sont plus faciles à maintenir, à déboguer, et à comprendre par les autres développeurs (et par vous-même dans le futur).
• Tests unitaires exhaustifs et couvrant tous les cas d'utilisation : Ecrivez des tests unitaires exhaustifs qui couvrent un large éventail de cas de test pertinents, en incluant :
  • Cas nominaux (happy path) : Validez le comportement de la fonction pour les entrées valides et les cas d'utilisation normaux.
  • Cas limites (edge cases) : Testez les cas limites ou les cas aux frontières du domaine de validité de la fonction, avec des entrées limites ou des valeurs extrêmes (valeurs minimales, maximales, valeurs nulles, chaînes vides, etc.).
  • Cas d'erreur (error cases) : Testez le comportement de la fonction en cas d'erreurs ou d'entrées invalides, et vérifiez que la fonction gère correctement les erreurs et retourne les erreurs attendues.
• Utiliser les Table-Driven Tests pour les tests répétitifs : Utilisez les table-driven tests (chapitre 20) pour simplifier et organiser l'écriture de tests unitaires répétitifs, en particulier pour les fonctions qui doivent être testées avec un grand nombre de cas de test. Les table-driven tests rendent les tests plus concis, plus lisibles, et plus faciles à étendre et à maintenir.
• Utiliser des assertions précises et informatives (t.Errorf, t.Fatalf, outils d'assertions tiers) : Effectuez des assertions précises et informatives dans vos tests unitaires pour vérifier les résultats attendus. Utilisez les fonctions d'assertion du package testing (t.Errorf, t.Fatalf) et/ou des bibliothèques d'assertions tierces (comme testify/assert, github.com/stretchr/testify/assert) pour simplifier l'écriture des assertions et améliorer le reporting des erreurs.
• Exécuter les tests unitaires fréquemment et automatiquement (intégration continue - CI) : Exécutez vos tests unitaires fréquemment (par exemple, à chaque modification de code, avant chaque commit, ou de manière périodique) pour détecter les bugs et les régressions le plus tôt possible dans le cycle de développement. Automatisez l'exécution des tests unitaires en les intégrant dans votre pipeline CI/CD (Continuous Integration/Continuous Delivery), afin que les tests soient exécutés automatiquement à chaque build ou à chaque déploiement, garantissant ainsi une qualité continue du code.

En respectant ces conventions pour l'écriture de tests unitaires en Go, vous construirez une suite de tests unitaires robuste, efficace, facile à maintenir, et qui vous apportera une confiance élevée dans la qualité, la fiabilité, et la correction de votre code Go.