Trop de mock tue le test : ce que l'archi hexagonale a changé

Notre chemin vers les tests automatisés commence souvent par ces certitudes :
1 Test Unitaire = 1 méthode d'une seule classe
Remplaçons toute autre classe par un Mock
Toute classe a son Test Unitaire, pour respecter la pyramide de tests
Mais ces tests vous aident-ils lors du refactoring, ou devez-vous sans cesse les modifier, devenant des Tests Fragiles ? Les écrivez-vous vraiment en premier pour vous servir d'aide, ou vous freinent-ils à la fin de votre travail ?
Chez Meetic, l'Architecture Hexagonale (ou Ports & Adapters) et le DDD ont révolutionné notre manière de tester. Avec des exemples concrets de code et de refactoring, découvrez :
Ce que Unitaire dans Test Unitaire signifie réellement
Comment nous testons nos fonctionnalités métier en ne mockant que les détails techniques
Pourquoi nous jetons nos Tests Unitaires sur les couches techniques pour ne garder que des Tests d'Intégration avec wiremock-php et docker-compose

Comments

Comments are closed.