Présentation

Présentation _ Qui est KNP ?

Fondé en 2009

30 KNPeers : devs, fafas, UX designers, alternants

2 agences : Nantes, Caen

We Care.

Développement

sur mesure

Expertise technique sur Symfony / React.JS

Méthodologie KNP permettant d'extraire les besoins spécifiques

Accompagnement et aide à la décision technique et fonctionnelle

Présentation _ Savoir-faire

Méthodologie

agile

Méthodologie basée sur les fondements agiles 

Amélioration continue tout au long des projets

2 coachs certifiés Scrum Master accompagnent l'équipe et les clients

Accompagnement

personalisé

Conseil et accompagnement sur l'orchestration des SI

Expertise sur Docker / Cloud / Ansible / Kubernetes / Swarm…

Accompagnement et mise en place de migration d'hébergement

Et aussi ...

• Formations
• Consulting techniques
• Audit techniques et process

Apps mobiles

Présentation _ Réalisations

Sites publics à fort

trafic

Outils internes de gestion de production

Défimedoc, Deliver events, ...

Imparfaite Paris, 9e store, ...

Brand & Shop, Packaging, anaka, ...

Contexte

Gestion de la production

400 utilisateurs

Tests d'intégration avec MSWJS _ Contexte

Anakà

Objectif zéro papier

Stack technique

SPA React / Redux / Redux-Saga

API Symfony + mercure pour le temps réel

Tests d'intégration avec MSWJS _ Contexte

Rappels élémentaires

Tests d'intégration avec MSWJS _ Contexte

Problème :

Approche unitaire

Tests unitaires

• Composants React montés avec un store redux de test sans side effects
• Reducers & sélecteurs
• Side effects testés a part (sagas, epics, thunks, ...)

Tests d'intégration avec MSWJS _ Approche unitaire

Ecole fonctionnelle

• Robustesse garantie par la composition de fonctions pures unitairement testées

Tests de selecteurs

• Chronophage et verbeux alors que certains sélecteurs ne sont que des accesseurs
• Répétitifs

Tests de side effects (appels d'API, clipboard, local storage, ...)

• Quel comportement tester ? Action in -> action out
• Nécessaire de mocker le comportement des dépendances
• 90% des side effects sont des appels d'APIs (succès / erreur)
• Verbeux et répétitifs
• Peu lisibles / maintenables (marble testing) ...
• ... voire carrément contreproductifs

Tests d'intégration avec MSWJS _ Approche unitaire

Tests de composants React

• React testing library
• Tests en isolation (sans les side effects)
• Simulation des comportements en dispatchant nous-mêmes des actions (act)
• Exemple : actions succès / erreur après un appel d'API

Tests d'intégration avec MSWJS _ Approche unitaire

Risques de faux positifs

• Si on supprime / modifie l'effect qui est normalement responsable de dispatcher ces actions dans l'app, les tests passeront toujours, mais l'app est KO

Risques de faux négatifs

• Si on arrête de dispatcher ces actions dans les tests, ils sont KO alors que l'app va très bien

Tests d'intégration avec MSWJS _ Approche unitaire

Un bilan mi-figue mi-raisin

• Les composants fonctionnent tous en isolation mais...
• Les conditions d'exécution sont éloignées de la réalité
• On teste l'implémentation plutôt que le comportement
• Tests chronophages, répétitifs et verbeux
• Pour un gain de confiance faible

Tests d'intégration avec MSWJS _ Approche unitaire

Approche en intégration

Articles de référence

• Kent C. Dodds. Write tests. Not too many. Mostly integration. 2019.

https://kentcdodds.com/blog/write-tests

• Adam Bender. SMURF: Beyond the Test Pyramid. 2024.

https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html

Pourquoi tester l'intégration de nos composants ?

• Plutôt que de tout tester de la même manière et de façon peu efficace, on déplace l'effort de test pour le centrer sur le comportement de l'utilisateur
• Plus proche de la philosophie de react-testing-library

Tests d'intégration avec MSWJS _ Approche en intégration

Tests d'intégration avec MSWJS _ Approche en intégration

Tests d'intégration

• Composants React montés avec le store redux et les side effects
• Ils sont desormais testés dans les conditions réelles d'exécution de l'app
• Utilisation de MSWJS pour intercepter les appels réseaux

Tests unitaires

• Side effects complexes uniquement (i.e. authentification)
• Reducers
• Sélecteurs complexes uniquement

Tests d'intégration avec MSWJS _ Approche en intégration

Serveur

Tests d'intégration avec MSWJS _ Approche en intégration

Handlers

Tests d'intégration avec MSWJS _ Approche en intégration

Tests d'intégration avec MSWJS _ Exemple

Scénario nominal

Tests d'intégration avec MSWJS _ Exemple

Scénario d'échec

Fixtures

• Testées unitairement en utilisant les JSON schémas du backend...
• ...tout comme les données que l'on envoie à l'API, dans les handlers de MSW

Tests d'intégration avec MSWJS _ Approche en intégration

Quid des tests E2E ?

Conséquences

Les sélecteurs type accesseurs sont testés "indirectement"

• Plus besoin de les tester unitairement

La plupart des side effects sont aussi testés indirectement à partir du moment où l'interface change en réaction à une action système

• Plus besoin de les tester unitairement ni même de les exporter (= simplification)

Plus besoin de dispatcher des actions à la main pour simuler un comportement

• Tests plus lisibles et plus simples à maintenir

Moins de faux positifs

• Davantage de confiance dans ce qu'on livre
• Diminution du risque de régression
• Gain de sérénité

Tests d'intégration avec MSWJS _ Conséquences

Limites

Risque de tests un peu instables lors de certains enchaînements

Prise en main : tout est asynchrone !

• Résolution des réponses de MSW potentiellement instantanées
• Besoin d'attendre que les éléments de l'interface soient tous là pour les assertions et passer au test suivant

Plus lents que des tests unitaires

• (100 suites / 500 tests ~ 50s)

Tests d'intégration avec MSWJS _ Limites