Aller au contenu

Moyens et dépendances de test

"Un test fiable est un test qui contrôle ses dépendances."

Principe du testing moderne

Objectifs pédagogiques

À la fin de cette page, vous serez capable de :

  • expliquer ce qu’est une dépendance
  • comprendre pourquoi elles posent problème
  • identifier les moyens pour les maîtriser
  • connaître les principaux doubles de test

Qu’est-ce qu’une dépendance ?

Une dépendance est tout élément externe dont dépend le fonctionnement d’un composant testé :

  • base de données
  • service externe
  • API
  • système tiers
  • horloge, réseau, fichiers

👉 Les dépendances rendent les tests : - plus lents - moins fiables - plus difficiles à reproduire

Pourquoi maîtriser les dépendances ?

Sans maîtrise : - tests instables - faux positifs / faux négatifs - débogage complexe

Avec maîtrise : - tests rapides - résultats fiables - meilleure isolation

Les doubles de test

Pour remplacer les dépendances, on utilise des doubles de test :

Types principaux

  • Dummy : objet de remplissage
  • Stub : retourne des valeurs prédéfinies
  • Spy : observe les appels
  • Mock : vérifie les comportements attendus
  • Fake : implémentation simplifiée mais fonctionnelle
  • Fixture : état initial de test

👉 En pratique, le terme mock est souvent utilisé de manière générique.

Image title

Les Mocks

Détails des principaux doubles de test

Les doubles de test permettent de remplacer des dépendances réelles par des objets contrôlés. Ils servent à isoler le composant testé et à rendre les tests prévisibles et reproductibles.

Rôle
Objet factice utilisé uniquement pour remplir un paramètre obligatoire.
Il n’a aucun comportement et n’est jamais réellement utilisé.

Quand l’utiliser ? Quand un paramètre est obligatoire mais inutile pour le test

Exemple MyEvents
Lors d’un test unitaire sur la création d’un événement, un objet Utilisateur est requis, mais ses données ne sont pas utilisées dans le test.

→ On fournit un utilisateur « vide ».

Analogie du quotidien
👉 Mettre un faux numéro de téléphone dans un formulaire juste pour pouvoir passer à l’étape suivante.

Rôle
Fournit des réponses prédéfinies à des appels, sans logique interne.

Quand l’utiliser ? Quand tu veux tester un scénario précis (succès, échec, limite)

Exemple MyEvents
Le service de paiement retourne toujours : - paiement accepté - ou paiement refusé

sans appeler Stripe ou PayPal.

Analogie du quotidien
👉 Une répondeur automatique qui dit toujours le même message, peu importe la question.

Rôle
Observe les appels effectués vers une dépendance : - combien de fois ? - avec quels paramètres ?

Quand l’utiliser ? Quand tu veux vérifier qu’une action a bien eu lieu

Exemple MyEvents
Vérifier que le service d’e-mail est bien appelé une seule fois après un achat de billet.

Analogie du quotidien
👉 Quelqu’un qui note combien de fois tu appelles quelqu’un, sans intervenir.

Rôle
Combine : - des réponses prédéfinies - des attentes sur le comportement

Le test échoue si le comportement attendu n’est pas respecté.

Quand l’utiliser ? Quand le comment est aussi important que le résultat

Exemple MyEvents
Vérifier que : - l’API de paiement est appelée - avec le bon montant - dans le bon ordre

Analogie du quotidien
👉 Un contrôleur qui vérifie que tu fais exactement ce qui était prévu.

Rôle
Implémentation simplifiée mais fonctionnelle d’une dépendance.

Quand l’utiliser ? Pour tester sans dépendre d’un vrai système externe

Exemple MyEvents
Une fausse base de données en mémoire pour stocker : - événements - utilisateurs - billets

sans base de données réelle.

Analogie du quotidien
👉 Une caisse d’entraînement dans un magasin pour former les employés.

Rôle
Ensemble de données ou d’état initial utilisé pour préparer un test.

Quand l’utiliser ? Pour garantir la reproductibilité

Exemple MyEvents
- un utilisateur existant - un événement actif - des billets disponibles

chargés avant chaque test.

Analogie du quotidien
👉 Préparer la table avant de manger : tout est prêt avant de commencer.

Moyens techniques

Pour gérer les dépendances, on peut utiliser :

  • frameworks de mock
  • injection de dépendances
  • environnements isolés
  • données de test contrôlées
  • virtualisation de services

Injection de dépendances

Qu’est-ce que l’injection de dépendances ?

L’injection de dépendances consiste à fournir les dépendances à un composant,
au lieu de les créer directement à l’intérieur.

Le composant ne choisit pas ses dépendances, on les lui donne.

Pourquoi est-ce essentiel pour les tests ?

Sans injection :

  • dépendances figées
  • tests couplés
  • tests lents et fragiles

Avec injection :

  • dépendances remplaçables
  • tests rapides
  • isolation totale

Exemple conceptuel

Sans injection :

ServicePaiement
 └── crée Stripe directement

Avec injection :

ServicePaiement
 └── reçoit un ServicePaiementExterne
        ├── Stripe (prod)
        └── MockStripe (test)

Avantages :

  • en test, on injecte un mock
  • en production, on injecte la vraie API
  • le code du service ne change pas

Bonnes pratiques

  • isoler au maximum les tests unitaires
  • documenter les dépendances critiques
  • éviter les tests trop couplés
  • privilégier la simplicité

Exemple concret – Dépendances dans l’application MyEvents

Dans l’application MyEvents

, de nombreuses fonctionnalités reposent sur des dépendances externes, notamment :

  • une API de paiement (Stripe / PayPal)
  • un service d’envoi d’e-mails et SMS (SendGrid, Twilio)
  • une API de géolocalisation (Google Maps)
  • une base de données utilisateur partagée

Ces dépendances posent plusieurs défis lors des tests : - elles peuvent être indisponibles - elles sont parfois payantes - elles introduisent de la latence - elles rendent les tests non déterministes

Maîtrise des dépendances dans MyEvents

Exemple : paiement d’un billet

Lorsqu’un utilisateur achète un billet :

  • MyEvents appelle l’API de paiement
  • reçoit une réponse (succès ou échec)
  • met à jour la base de données
  • déclenche l’envoi d’une notification

👉 Tester ce scénario sans maîtriser les dépendances rend les tests : - lents - instables - dépendants de services externes

Utilisation de doubles de test dans MyEvents

Pour fiabiliser les tests, on peut utiliser :

  • Stub de l’API de paiement
    → retourne systématiquement un paiement accepté ou refusé

  • Mock du service e-mail
    → vérifie qu’un e-mail aurait été envoyé, sans l’envoyer réellement

  • Fake base de données
    → stockage temporaire en mémoire pour les tests

Exemple

Lors d’un test unitaire : - l’API de paiement est simulée - aucun appel réel à Stripe n’est effectué - le test vérifie uniquement la logique métier de MyEvents

Lien avec la pyramide de test

  • Tests unitaires
    → dépendances fortement simulées (mocks, stubs)

  • Tests d’intégration
    → dépendances partiellement réelles (API de test, sandbox)

  • Tests E2E
    → dépendances réelles mais contrôlées

👉 Plus on monte dans les niveaux de test, moins on simule, mais plus on contrôle l’environnement.

Image title

Ràsimé Pizza

À retenir

  • Les dépendances sont inévitables dans une application moderne
  • Leur maîtrise est essentielle pour :
    • des tests fiables
    • une automatisation efficace
    • une maintenance durable
  • Les doubles de test sont des outils stratégiques, pas des contournements

⬅ Modèle en V & pyramide ➡ Tests fonctionnels