Questions d'entretien Tests et Qualite
1. Expliquez la pyramide des tests et son importance.
La pyramide des tests (Mike Cohn) recommande une repartition : beaucoup de tests unitaires (rapides, isoles, coutent peu), moins de tests d'integration (verifient 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'idee : les tests unitaires detectent la majorite des bugs rapidement et a moindre cout. Les tests E2E verifient les scenarios 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 etapes : Red (ecrire un test qui echoue), Green (ecrire le minimum de code pour que le test passe), Refactor (ameliorer le code en gardant les tests verts). Le TDD force a penser a l'API avant l'implementation, produit un code naturellement testable, et fournit une documentation executable. Le TDD n'est pas adapte a tout (prototypage, UI pure), mais est excellent pour la logique metier et les algorithmes.
3. Quelle est la difference entre mocks, stubs et fakes ?
Les stubs retournent des reponses predefinies (pas de verification d'appel). Les mocks sont des stubs qui verifient aussi que certaines methodes ont ete appelees avec les bons arguments. Les fakes sont des implementations simplifiees fonctionnelles (base de donnees en memoire, serveur HTTP de test). Les spies enregistrent les appels recus pour verification ulterieure. Regle : preferez les stubs pour les dependances dont vous ne testez pas le comportement, les mocks quand l'interaction est le sujet du test.
4. Comment tester du code qui depend de services externes ?
Strategies par ordre de fidelite croissante : Mock/Stub au niveau de l'interface (rapide mais ne teste pas l'integration), Fake avec une implementation en memoire (bon equilibre), Conteneur de test avec Testcontainers (base de donnees reelle dans Docker), Environnement de staging (le plus fidele mais le plus lent/couteux). Pour les API externes : WireMock ou MSW (Mock Service Worker) pour simuler les reponses. Privilegiez les tests d'integration 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 qualite 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 qualite que la couverture de code.
6. Comment structurer les tests pour qu'ils soient maintenables ?
Pattern Arrange-Act-Assert (AAA) : separez la preparation, l'action et la verification. Un seul concept par test : un test qui echoue doit indiquer clairement ce qui ne marche pas. Nommage descriptif : le nom du test decrit le scenario et le resultat attendu. DRY vs DAMP : en tests, la lisibilite (DAMP - Descriptive And Meaningful Phrases) est plus importante que la factorisation (DRY). Evitez la logique conditionnelle dans les tests. Utilisez des builders ou factories pour les donnees de test complexes.
7. Qu'est-ce que le contract testing et quand l'utiliser ?
Le contract testing verifie que les interactions entre services respectent un contrat (schema de requete/reponse). L'outil de reference est Pact. Le consommateur (client) definit ses attentes, le producteur (API) verifie qu'il les satisfait. C'est ideal en architecture microservices : chaque service peut etre teste independamment, et les incompatibilites sont detectees avant le deploiement. Le contract testing remplace avantageusement les tests d'integration couteux entre services.
8. Comment gerer les tests flaky (instables) ?
Les tests flaky echouent de maniere intermittente. Causes courantes : dependances au timing (sleep, setTimeout), etat partage entre tests, dependances au reseau, conditions de concurrence. Solutions : isolez chaque test (reset de l'etat), remplacez les sleeps par des attentes explicites (waitFor, polling), mockez les services externes, utilisez des seeds deterministes pour les donnees aleatoires, 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 a deplacer les activites de test vers le debut du cycle de developpement. Au lieu de tester apres le developpement, testez pendant et meme avant. Pratiques : TDD (tests avant le code), revues de code (detection de bugs par les pairs), analyse statique dans la CI (linting, SAST), tests unitaires a chaque commit, tests de securite automatises (DAST dans la CI), definition of ready incluant les criteres de test. Le cout de correction d'un bug augmente exponentiellement au fil du cycle de vie.
10. Comment mesurer la qualite d'une suite de tests ?
Metriques : couverture de code (necessaire mais insuffisante — 80% est un bon objectif), taux de mutation (qualite reelle des assertions), temps d'execution (une suite lente n'est pas executee), taux de tests flaky (objectif : 0%), delai de detection des bugs (combien de temps entre l'introduction et la detection), ratio tests/code (indicateur de discipline de test). La metrique la plus importante : la confiance que l'equipe a dans la suite de tests pour deployer sans peur.