🧪 Mock Me If You Can : Guide de Survie des Tests Logiciels
Ah, les tests. Ce mot magique qui peut transformer un commit innocent en un feu d'artifice rouge dans ton pipeline CI.
Tu pensais avoir tout compris ? Détrompe-toi, camarade développeur chevronné.
Voici un tour d'horizon (un peu) technique, (légèrement) sarcastique et (probablement) pertinent des principaux types de tests logiciels :
- ✅ Tests unitaires (mockistes vs classicists)
- 🔌 Tests d'intégration
- 🧪 Tests end-to-end (E2E)
- 🔥 Tests de charge
La fameuse pyramide des tests : moins tu montes, mieux tu dors.
🎬 Bonus : Notre Talk "La Légende des Gardiens du Code"
🗣️ Tu préfères regarder plutôt que lire ? On t'a couvert !
Le 06 juin 2024, avec mon acolyte Jeremy Bernard, on a donné un talk au DevQuest sur ce sujet brûlant : les types de tests et la CI/CD qui va avec.
🎥 Le Talk en Vidéo
📺 Regarder "La Légende des Gardiens du Code" sur YouTube
📊 Les Slides de la Conférence
💾 Télécharger le PowerPoint de la conférence
Spoiler alert : On y raconte comment les tests sont les vrais gardiens de votre code... et pourquoi sans eux, c'est l'anarchie totale en production ! 🔥
🧩 Tests Unitaires : Mockistes vs Classicists — Le Match de Boxe
"Un bon test unitaire isole. Un test unitaire parfait n'existe pas."
— Un développeur qui a perdu 3 jours à débugger un mock
🥊 Camp 1 : Les Mockistes (a.k.a. London School)
Tu veux tout contrôler ? Tu adores faire semblant ? Bienvenue chez les mockistes.
Ici, chaque dépendance est simulée. Tu ne veux pas tester si fetchData() accède à une vraie BDD, tu veux juste qu'il croie qu'elle existe.
✅ Avantages
- Hyper rapide
- Super précis : tu sais exactement ce qui est cassé
- Isolation complète du code testé
❌ Inconvénients
- Fragile comme un test PCR dans une boîte chaude
- Teste souvent l'implémentation plus que le comportement
- Maintenance élevée des mocks
🧘♂️ Camp 2 : Les Classicists (a.k.a. Detroit School)
Tu préfères tester sans te casser la tête à tout mocker ? Tu es classicist.
Tu laisses les vraies dépendances s'exécuter dans leur contexte logique.
✅ Avantages
- Teste des comportements réels
- Moins de maintenance liée aux mocks
❌ Inconvénients
- Moins rapide
- Plus sujet aux tests flakies
- Risque de mauvaise séparation des responsabilités
🤯 Le Vrai Dilemme ?
- Les mockistes valident les interactions
- Les classicists valident les résultats
👉 Choisis ton camp, mais reste cohérent.
🔌 Tests d'Intégration : Là où les Bugs naissent
"Ça marche en local, mais en prod c'est l'apocalypse ? Tu fais pas de tests d'intégration, hein ?"
Le test d'intégration, c'est le café serré du TDD.
Il ne teste pas chaque grain, mais la machine complète.
✅ Avantages
- Révèle les vrais bugs (ceux qui pètent en prod)
- Valide les comportements transverses : transactions, configs, etc.
❌ Inconvénients
- Lents, très lents
- Fragiles si dépendances instables
- Requiert souvent un environnement spécifique ou des outils comme Testcontainers, WireMock, etc.
🔧 Schéma 1: Test d'Intégration Multi-Couches
"Quand toutes les couches doivent jouer ensemble... sans se disputer"
┌─────────────────────────────────────────────────────────────┐
│ 🖥️ COUCHE UI (Frontend) ✅ UI répond │
├─────────────────────────────────────────────────────────────┤
│ • Formulaire de commande │
│ • Saisie produit: "Licorne en peluche" │
│ • Quantité: 42 (pourquoi pas ?) │
│ │
│ form.submit() // Pray it works 🙏 │
└─────────────────────────────┬───────────────────────────────┘
│ ⬇️ Test vérifie la transmission
┌─────────────────────────────▼───────────────────────────────┐
│ ⚙️ COUCHE API (Backend) ✅ API traite │
├─────────────────────────────────────────────────────────────┤
│ • Endpoint REST /orders │
│ • Validation des données │
│ • Calcul du prix (licornes = €€€) │
│ │
│ POST /api/orders │
│ status: 201 │
└─────────────────────────────┬───────────────────────────────┘
│ ⬇️ Test vérifie la persistance
┌─────────────────────────────▼───────────────────────────────┐
│ 🗄️ COUCHE BASE DE DONNÉES ✅ DB persiste │
├─────────────────────────────────────────────────────────────┤
│ • Tables: products, orders, customers │
│ • Transaction ACID │
│ • Contraintes respectées │
│ │
│ INSERT INTO orders -- Magic happens here ✨ │
└─────────────────────────────┬───────────────────────────────┘
│ ⬇️ Test vérifie l'appel externe
┌─────────────────────────────▼───────────────────────────────┐
│ 💳 SERVICES EXTERNES ✅ Paiement OK │
├─────────────────────────────────────────────────────────────┤
│ • Service de paiement Stripe │
│ • Tokenisation carte │
│ • Débit de 1337.42€ │
│ │
│ stripe.charge() // 💸 Bye bye money │
└─────────────────────────────────────────────────────────────┘
🎉 Résultat du Test d'Intégration
✓ Formulaire → API : PASS
✓ API → Base de données : PASS
✓ API → Service paiement : PASS
✓ Cohérence des données : PASS
🤓 "Un test d'intégration, c'est comme un chef d'orchestre :
il faut que tous les musiciens jouent la même partition...
sinon ça donne du jazz expérimental !"
🧪 Tests End-to-End (E2E) : Le Grand Frisson de l'Automatisation
"Si le bouton ne clique pas, le client ne paie pas."
Les tests E2E sont là pour simuler un vrai utilisateur.
Tu veux tester tout le flow : login, achat, logout ? C'est ici.
🛠️ Outils populaires :
✅ Avantages
- Simule le parcours utilisateur complet
- Détecte les régressions UI ou frontend/backend
❌ Inconvénients
- Lents. Très lents.
- Fragiles. Très fragiles.
- Maintenance élevée (un QA engineer peut y passer sa vie)
🤖 Schéma 2: E2E Testing vs Human Testing
"Même parcours, même vérifications, mais qui gagne ?"
L'Affrontement Épique
┌─────────────────────────────┐ ⚔️ VS ⚔️ ┌─────────────────────────────┐
│ 👨💻 L'HUMAIN TESTEUR │ │ 🤖 LE TEST E2E │
├─────────────────────────────┤ ├─────────────────────────────┤
│ │ │ │
│ 🧑💼 │ │ 🤖 │
│ │ │ │
│ 💭 "Bon, on va tester │ │ 💭 "BEEP BOOP. Exécution │
│ cette app... encore... │ │ du scénario 1337..." │
│ pour la 47ème fois..." │ │ │
│ │ │ │
│ ACTIONS: │ │ CODE: │
│ │ │ │
│ 1. 🖱️ Ouvre le navigateur │ │ cy.visit('localhost:3000') │
│ *soupir* Firefox ou │ │ │
│ Chrome aujourd'hui ? │ │ cy.get('[data-testid=form]')│
│ │ │ .should('be.visible') │
│ 2. ⌨️ Tape l'URL │ │ │
│ localhost:3000... enfin │ │ cy.get('#email') │
│ j'espère que c'est ça │ │ .type('test@example.com') │
│ │ │ │
│ 3. ⏳ Attend le chargement │ │ cy.get('button[type=submit]')│
│ Hmm... c'est long là... │ │ .click() │
│ ça marche ? │ │ │
│ │ │ cy.contains('Success!') │
│ 4. 👀 Regarde l'interface │ │ .should('be.visible') │
│ "Tiens, ce bouton a │ │ │
│ bougé de 2px..." │ │ │
│ │ │ ⚡ Temps d'exécution: 0.3s │
│ 5. 📝 Remplit le formulaire │ │ 🎯 Précision: 100% │
│ Email: test@test.com │ │ 🔄 Répétable: ∞ fois │
│ (encore et toujours) │ │ 📊 Rapports: Automatiques │
│ │ │ │
│ 6. 📤 Clique sur Submit │ │ │
│ *croise les doigts* │ │ 💭 "BEEP BOOP. Test terminé│
│ │ │ Prêt pour les 999 │
│ 7. ✅ Vérifie le résultat │ │ autres scénarios..." │
│ "Success!" - Ouf, ça │ │ │
│ marche... cette fois │ │ │
│ │ │ │
│ 💭 "Bon, maintenant il faut │ │ │
│ que je teste avec un │ │ │
│ autre email... et sur │ │ │
│ mobile... et Safari😵" │ │ │
└─────────────────────────────┘ └─────────────────────────────┘
🏆 Verdict du Match
| Critère | 👨💻 Humain | 🤖 Robot | Gagnant |
|---|---|---|---|
| Vitesse | 3 minutes | 0.3 secondes | 🤖 >>> 👨💻 |
| Précision | "Oups, cliqué à côté" | Chirurgicale | 🤖 > 👨💻 |
| Répétabilité | "Pas un lundi matin..." | 24h/24, 7j/7 | 🤖 >>> 👨💻 |
| Créativité | "Et si je clique là ?" | Suit le script | 👨💻 >>> 🤖 |
| Détection de bugs bizarres | "En diagonale ça plante" | Ne sort jamais du script | 👨💻 >>> 🤖 |
🤝 La Vérité
L'E2E teste comme un humain très discipliné qui n'aurait jamais de lundi matin...
Mais qui ne trouvera jamais le bug bizarre qui arrive seulement "quand on fait ça en diagonale" 🤷♂️
🔥 Tests de Charge : T'as Pas Crashé, Donc T'as Gagné
"Tu peux scaler ton app à 1 million d'utilisateurs ? Moi non plus. Mais j'ai un test qui dit que peut-être."
Tu veux savoir ce que devient ton API sous pression ? Tu fais des tests de charge.
🛠️ Outil testé:
✅ Avantages
- Identifie les goulets d'étranglement
- Fournit des metrics (latence, taux d'erreur, throughput)
- Essentiel en préprod sur les services critiques
❌ Inconvénients
- Difficiles à calibrer et interpréter
- Peuvent donner un faux sentiment de sécurité
- Nécessitent une vraie stratégie d'analyse
⚖️ Résumé Comparatif
| Type de test | Vitesse 🚀 | Fiabilité 🛡️ | Portée 🎯 | Complexité 🧠 |
|---|---|---|---|---|
| Unitaire (mock) | Ultra rapide | Moyenne | Petite | Moyenne |
| Unitaire (classic) | Rapide | Bonne | Moyenne | Basse à moyenne |
| Intégration | Moyenne | Moyenne | Moyenne à large | Moyenne à haute |
| End-to-End (E2E) | Lente | Moyenne | Large | Haute |
| Charge | Variable | Bonne (si bien fait) | Large | Haute |
👋 Conclusion : Teste intelligemment, pas aveuglément
Les tests ne sont pas là pour faire joli sur un dashboard.
Ils sont là pour te sauver le c*l à 2h du matin quand la prod tombe.
✅ Reste pragmatique
✅ N'overengineere pas tes tests
✅ Utilise le bon test pour le bon usage
Et surtout :
Si tu commites sans tests, assume quand tout pète. 😈
📌 Tu veux plus d'articles techniques ?
Suis-moi ici sur dev.to, ou viens troller (gentiment) en commentaires.
#DevOps #TDD #Testing #SoftwareCraftsmanship #TestezVosProds
Top comments (0)