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

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

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

64822af642dacc617380f009e35a78f7?s=128

Jean-Marie Lamodière

October 22, 2020
Tweet

Transcript

  1. Icons made by Icongeek26, Freepik from www.flaticon.com

  2. Tests de verrouillage vs. TDD Icons made by Roundicons from

    www.flaticon.com
  3. Icons made by Freepik from www.flaticon.com https://github.com/JMLamodiere/tdd-demo-forumphp2020

  4. Previously...

  5. • Un Test Fonctionnel décrit un fonctionnement • Un Test

    Unitaire verrouille une implémentation Idée reçue #1 Icons made by Freepik from www.flaticon.com
  6. • Un Test Fonctionnel décrit un fonctionnement • Un Test

    Unitaire verrouille une implémentation Idée reçue #1 Icons made by Roundicons from www.flaticon.com Tous les tests décrivent le fonctionnement attendu des méthodes / API publiques Seules l’audience et la taille de la zone couverte varient.
  7. Seuls les tests fonctionnels ont 3 étapes : • Given

    • When • Then Idée reçue #2 Icons made by Freepik from www.flaticon.com
  8. Seuls les tests fonctionnels ont 3 étapes : • Given

    • When • Then Idée reçue #2 Icons made by Roundicons from www.flaticon.com Tous les tests suivent le schéma narratif : • Given = Arrange • When = Act • Then = Assert Situation initiale Elément déclencheur Situation finale
  9. Idée reçue #3 Icons made by Freepik from www.flaticon.com Vérifier

    le nombre d’appels à toutes les méthodes mockées augmente ma confiance. ->expects($this->exactly(1))->method('xxx') ->shouldBeCalledTimes(1)
  10. Idée reçue #3 Vérifier le nombre d’appels à toutes les

    méthodes mockées augmente ma confiance. ->expects($this->exactly(1))->method('xxx') ->shouldBeCalledTimes(1) Icons made by Roundicons, Smashicons from www.flaticon.com • Brouille l’intention du test • Verrouille des détails d'implémentation • Impossible à écrire en premier
  11. Quoi tester ?

  12. Idée reçue #4 Icons made by Freepik from www.flaticon.com Je

    peux mocker les librairies utilisées côté Infrastructure : • Http : Guzzle… • Base de donnée : Doctrine, Eloquent…
  13. Idée reçue #4 Icons made by Roundicons, Smashicons from www.flaticon.com

    Je peux mocker les librairies utilisées côté Infrastructure : • Http : Guzzle… • Base de donnée : Doctrine, Eloquent… • Couplé aux détails d’utilisation de la lib • Suppositions sur son fonctionnement • Impossible à écrire en premier
  14. Infrastructure : test d’intégration Icons made by Freepik, Smashicons, Roundicons

    from www.flaticon.com
  15. Idée reçue #5 Icons made by Freepik from www.flaticon.com Test

    fonctionnel = forcément end to end
  16. Idée reçue #5 Icons made by Roundicons, smashicons from www.flaticon.com

    Test fonctionnel = forcément end to end • Lent • Fragile • Difficile à maintenir • Plus dur à écrire en premier • Verrouille trop tôt les choix d’infrastructure Suggestion : mocker Ports Secondaires
  17. Icons made by Freepik from www.flaticon.com Suggestion

  18. Je dois connaître le découpage de mes classes pour écrire

    mes tests Idée reçue #6 Icons made by Freepik from www.flaticon.com
  19. Je dois connaître le découpage de mes classes pour écrire

    mes tests Idée reçue #6 Icons made by Roundicons from www.flaticon.com • Découpage classes de prod != classes de test • Démarrer par une zone au contour certain
  20. Icons made by Freepik from www.flaticon.com 1er test: zone au

    contour certain
  21. Idée reçue #7 Icons made by Freepik from www.flaticon.com Si

    je ne mock pas mes Entités / DTO, trop de tests casseront si j’ajoute un champ
  22. Idée reçue #7 Icons made by Roundicons from www.flaticon.com Si

    je ne mock pas mes Entités / DTO, trop de tests casseront si j’ajoute un champ • Factori(es) de test avec champs facultatifs • Getter pas couvert ? Je le supprime
  23. Merci Icons made by Roundicons, Freepik from www.flaticon.com A vous

    de jouer ! • •