Isolation sans douleur : Mocks et fixtures dans les tests Go

Quand la réalité gêne : pourquoi avons-nous besoin de mocks et de fixtures en Go ?

Imaginez que vous testez une fonction qui envoie une notification par e-mail. Chaque exécution du test est un vrai e-mail dans la boîte de réception. Après dix tests, votre boîte est saturée et vos collègues maudissent le spam. Ou pire : la fonction accède à une API externe qui est payante ou qui ne fonctionne qu'une fois par jour.

Dans le monde de Go (ou Golang, comme on l'appelle souvent) les tests ne sont pas simplement une case à cocher dans une liste. C'est le fondement de la fiabilité. Mais pour que les tests soient rapides et indépendants, nous devons isoler le code du monde extérieur. C'est ici qu'entrent en scène les objets mock (mocks) et les fixtures.

Dans cet article, nous verrons comment remplacer correctement les dépendances (mocker) et préparer les données (fixtures) en Go. Vous apprendrez à écrire des tests qui ne tombent pas en panne à cause du réseau, de la base de données ou de l'heure de la journée. C'est parti !

Que sont les Mock et Fixture dans le contexte de Go ?

Objets Mock : des doublures pour les systèmes complexes

Les objets Mock sont des "bouchons" logiciels qui imitent le comportement de composants réels. Au lieu d'appeler une vraie base de données ou un service HTTP, nous substituons un objet qui renvoie des réponses prédéfinies.

En Go, les mocks sont particulièrement importants car le langage encourage le travail avec des interfaces. Si votre code dépend d'une interface, vous pouvez facilement remplacer l'implémentation par une version de test.

Fixtures : préparer le terrain

Les Fixtures sont des données ou un état qui doivent être mis en place avant le début du test. Par exemple, la création d'une base de données temporaire, son remplissage avec des enregistrements de test ou la configuration du système de fichiers.

Contrairement aux mocks qui remplacent le comportement, les fixtures préparent l'environnement. Elles répondent à la question : "Que doit être prêt pour que le test puisse démarrer ?"

Écrire des mocks en Go : du simple au complexe

La méthode la plus simple : implémentation manuelle de l'interface

Go n'exige pas de bibliothèques spéciales pour créer des mocks. Si vous avez une interface, vous pouvez écrire son implémentation de test manuellement. C'est idéal pour les petits projets.

Supposons que nous ayons une interface pour envoyer des notifications :

package notifier\n\ntype Notifier interface {\n    Send(to string, message string) error\n}\n\n// Implémentation réelle (pas pour les tests)\ntype EmailNotifier struct{}\n\nfunc (e *EmailNotifier) Send(to string, message string) error {\n    // Envoi d'un vrai e-mail\n    return nil\n}

Dans le fichier de test, nous créons un mock :

package notifier\n\nimport "testing"\n\ntype MockNotifier struct {\n    Called bool\n    LastTo string\n    LastMsg string\n}\n\nfunc (m *MockNotifier) Send(to string, msg string) error {\n    m.Called = true\n    m.LastTo = to\n    m.LastMsg = msg\n    return nil\n}\n\nfunc TestSendAlert(t *testing.T) {\n    mock := &MockNotifier{}\n    // Utilisation du mock dans une fonction qui accepte Notifier\n    SendAlert(mock, "user@test.com", "Hello!")\n    \n    if !mock.Called {\n        t.Error("La méthode Send n'a pas été appelée")\n    }\n    if mock.LastTo != "user@test.com" {\n        t.Errorf("Destinataire incorrect : %s", mock.LastTo)\n    }\n}

Avantages : contrôle total, aucune dépendance.
\nInconvénients : beaucoup de code passe-partout pour les interfaces complexes.

Utiliser testify/mock : puissant et pratique

La bibliothèque testify est la norme de facto pour les mocks en Go. Elle fournit un framework flexible pour créer des mocks avec vérification des arguments et du nombre d'appels.

Installation :

go get github.com/stretchr/testify

Exemple avec testify/mock :

package user\n\nimport (\n    "testing"\n    "github.com/stretchr/testify/mock"\n)\n\n// Définition de l'interface\ntype UserRepository interface {\n    GetUser(id int) (string, error)\n}\n\n// Création de la structure mock\ntype