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.

David Mohamed at 16:28 on 22 Oct 2020

Intelligent et pertinent comme d'habitude

super intéressant ! Je vais en garder des recettes :)

Maxime Veber at 17:45 on 22 Oct 2020

Franchement top. Si je devais donner un truc c'est que t'as été à plusieurs moment un peu au hasard. Bon vu que t'était pas mal dans l'interaction ça passe crème.

Lucas Legname at 12:13 on 23 Oct 2020

Conférence très intéressante! Permet de démonter quelques idées reçues sur les tests avec des exemples pertinents et bien trouvés!

Yann Eugoné at 14:09 on 23 Oct 2020

J'ai vraiment aimé l'approche et le côté direct de l'explication.