Questions d'entretien Tests et Qualité
1. Expliquez la pyramide des tests et son importance.
La pyramide des tests (Mike Cohn) recommande une répartition : beaucoup de tests unitaires (rapides, isolés, coutent peu), moins de tests d'intégration (vérifient les interactions entre composants), et peu de tests end-to-end (lents, fragiles, mais testent le flux complet). En haut, les tests manuels/exploratoires. L'idée : les tests unitaires detectent la majorité des bugs rapidement et à moindre coût. Les tests E2E vérifient les scénarios critiques. Un anti-pattern courant est la "pyramide inversee" avec trop de tests E2E et peu de tests unitaires.
2. Qu'est-ce que le TDD et comment le pratiquer ?
Le Test-Driven Development suit un cycle en 3 étapes : Red (écrire un test qui echoue), Green (écrire le minimum de code pour que le test passe), Refactor (améliorer le code en gardant les tests verts). Le TDD force à penser à l'API avant l'implémentation, produit un code naturellement testable, et fournit une documentation exécutable. Le TDD n'est pas adapte à tout (prototypage, UI pure), mais est excellent pour la logique métier et les algorithmes.
3. Quelle est la différence entre mocks, stubs et fakes ?
Les stubs retournent des réponses prédéfinies (pas de vérification d'appel). Les mocks sont des stubs qui vérifient aussi que certaines méthodes ont été appelees avec les bons arguments. Les fakes sont des implémentations simplifiees fonctionnelles (base de données en mémoire, serveur HTTP de test). Les spies enregistrent les appels recus pour vérification ulterieure. Règle : préférez les stubs pour les dépendances dont vous ne testez pas le comportement, les mocks quand l'interaction est le sujet du test.
4. Comment tester du code qui dépend de services externes ?
Stratégies par ordre de fidelite croissante : Mock/Stub au niveau de l'interface (rapide mais ne teste pas l'intégration), Fake avec une implémentation en mémoire (bon équilibre), Conteneur de test avec Testcontainers (base de données réelle dans Docker), Environnement de staging (le plus fidele mais le plus lent/coûteux). Pour les API externes : WireMock ou MSW (Mock Service Worker) pour simuler les réponses. Privilégiez les tests d'intégration avec des vrais conteneurs pour les parties critiques.
5. Qu'est-ce que le test de mutation et comment l'utiliser ?
Le test de mutation evalue la qualité de vos tests en introduisant des modifications ("mutants") dans le code source : changer un + en -, inverser une condition, supprimer un return. Si vos tests detectent le mutant (echouent), il est "tue". Si les tests passent toujours, le mutant "survit", revelant un manque dans votre suite de tests. Outils : Stryker (JavaScript/TypeScript), PIT (Java), mutmut (Python). Le taux de mutants tues est un meilleur indicateur de qualité que la couverture de code.
6. Comment structurer les tests pour qu'ils soient maintenables ?
Pattern Arrange-Act-Assert (AAA) : separez la préparation, l'action et la vérification. Un seul concept par test : un test qui echoue doit indiquer clairement ce qui ne marche pas. Nommage descriptif : le nom du test décrit le scénario et le résultat attendu. DRY vs DAMP : en tests, la lisibilité (DAMP - Descriptive And Meaningful Phrases) est plus importante que la factorisation (DRY). Évitez la logique conditionnelle dans les tests. Utilisez des builders ou factories pour les données de test complexes.
7. Qu'est-ce que le contract testing et quand l'utiliser ?
Le contract testing vérifie que les interactions entre services respectent un contrat (schéma de requête/réponse). L'outil de référence est Pact. Le consommateur (client) définit ses attentes, le producteur (API) vérifie qu'il les satisfait. C'est idéal en architecture microservices : chaque service peut être teste indépendamment, et les incompatibilites sont détectées avant le déploiement. Le contract testing remplace avantageusement les tests d'intégration coûteux entre services.
8. Comment gérer les tests flaky (instables) ?
Les tests flaky echouent de manière intermittente. Causes courantes : dépendances au timing (sleep, setTimeout), état partage entre tests, dépendances au réseau, conditions de concurrence. Solutions : isolez chaque test (reset de l'état), remplacez les sleeps par des attentes explicites (waitFor, polling), mockez les services externes, utilisez des seeds deterministes pour les données aléatoires, et mettez en quarantaine les tests flaky le temps de les corriger. Les tests flaky non corriges degradent la confiance dans toute la suite.
9. Qu'est-ce que le shift-left testing ?
Le shift-left consiste à déplacer les activités de test vers le début du cycle de développement. Au lieu de tester après le développement, testez pendant et même avant. Pratiques : TDD (tests avant le code), revues de code (détection de bugs par les pairs), analyse statique dans la CI (linting, SAST), tests unitaires à chaque commit, tests de sécurité automatises (DAST dans la CI), définition of ready incluant les critères de test. Le coût de correction d'un bug augmente exponentiellement au fil du cycle de vie.
10. Comment mesurer la qualité d'une suite de tests ?
Métriques : couverture de code (nécessaire mais insuffisante — 80% est un bon objectif), taux de mutation (qualité réelle des assertions), temps d'exécution (une suite lente n'est pas exécutée), taux de tests flaky (objectif : 0%), délai de détection des bugs (combien de temps entre l'introduction et la détection), ratio tests/code (indicateur de discipline de test). La métrique la plus importante : la confiance que l'équipe a dans la suite de tests pour déployer sans peur.