Video : https://youtu.be/rSO1y3lCBfk
ForumPHP 2020 : https://afup.org/talks/3414-trop-de-mock-tue-le-test-ce-que-l-archi-hexagonale-a-change
Github demo project : https://github.com/JMLamodiere/tdd-demo-forumphp2020
English Version : https://speakerdeck.com/jmlamodiere/too-many-mocks-killed-the-test-what-hexagonal-architecture-has-changed
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