Migration d'Enzyme vers la bibliothèque de tests React

Accueil InfoQ Actualités Migration de la bibliothèque de tests Enzyme vers React - Étude de cas Sentry

02 mars 2023 3 min de lecture

par

Bruno Couriol

L'équipe d'ingénierie de Sentry a récemment raconté sur son blog les pilotes et les leçons tirées de la migration de ses tests frontaux d'Enzyme vers la bibliothèque de tests React. La migration a été déclenchée par le manque de prise en charge par Enzyme des versions plus récentes de React. La migration a duré environ 20 mois et a impliqué 17 ingénieurs qui ont examiné environ 5 000 tests.

Les ingénieurs de Sentry ont décidé à plusieurs reprises de ne pas migrer leur base de tests vers React Testing Library (RTL) faute d'avantages suffisamment substantiels. L'équipe a rappelé :

Nous n’ajoutons pas des choses simplement parce qu’elles sont nouvelles. Nous évaluons soigneusement les nouvelles technologies pour comprendre les avantages qu’elles apportent à notre équipe. RTL nous était connu à l'époque, mais nous n'avions pas d'arguments solides quant aux raisons pour lesquelles nous devrions l'intégrer dans notre base de code. Enzyme, la bibliothèque que nous utilisions pour tester notre bibliothèque de composants, répondait toujours à nos besoins.

D'une part, Sentry était déjà engagé dans une vaste migration vers TypeScript, ce qui, associé au travail régulier sur le produit, occupait l'équipe d'ingénierie.

D’un autre côté, les tests enzymatiques prenaient souvent beaucoup de temps et l’équipe avait tout intérêt à améliorer la vitesse des tests.

(Source : blog d'ingénierie de Sentry)

Une preuve de concept a montré une amélioration des performances de 12 %, ce qui a été jugé insuffisant pour se lancer dans un énième long projet de migration. La preuve de concept a néanmoins prouvé que RTL présentait des avantages observables par rapport à Enzyme. Comme le rapporte l'équipe, Enzyme n'a pas testé l'accessibilité, n'a pas nettoyé automatiquement l'environnement de test et a souvent accédé directement au composant dans l'état du test. À l'inverse, RTL est plus proche des tests d'intégration et s'efforce de tester les cas d'utilisation des applications du point de vue de l'utilisateur. En particulier, RTL s’efforce d’éviter de tester les détails de mise en œuvre. Les modifications d'implémentation ne devraient interrompre un test que si elles introduisent effectivement un bug.

L'analyse des compromis a changé après la migration de Sentry vers TypeScript et le début de la mise à niveau vers React 17 (qui inclut React Hooks). L'équipe rappelle :

La migration [RTL] n'a toujours pas retenu beaucoup d'attention jusqu'à ce que nous travaillions sur la mise à jour de React vers la version 17. L'équipe principale de React avait complètement réécrit les composants internes de la bibliothèque et Enzyme utilisait directement un certain nombre de fonctionnalités internes de React.[…] Enzyme ne l'a pas fait. fonctionne à 100% avec cette nouvelle version de React, mais il existait un adaptateur sur le marché qui contournait ce problème et c'est ce que nous avons utilisé. Cependant, cette solution ne fonctionnerait pas à long terme car React 18 nécessiterait une réécriture complète, ce qui était peu probable étant donné qu'Airbnb avait abandonné le support d'Enzyme.[…] RTL ne s'appuie pas sur les composants internes de React. et continuerait à fonctionner de la même manière avec React 18 comme avec 16 et 17.

Une fois le feu vert donné, l'accent a été mis sur la minimisation des risques du projet de migration (estimations techniques sous diverses hypothèses, approche itérative vs migration big-bang, suivi des progrès, formation RTL, mise en évidence des meilleures pratiques, révisions quotidiennes du code, etc. ).

La migration s'est achevée au bout de 18 mois (contre 14 mois estimés). Cela a permis à l'équipe de supprimer les tests obsolètes, d'améliorer l'accessibilité (un aspect auparavant négligé) et d'écrire des tests basés sur des cas d'utilisation plutôt que sur des détails d'implémentation.

L'équipe a détaillé les problèmes de performances inattendus rencontrés en suivant à la lettre certaines recommandations de RTL (par exemple, en plus de se moquer des API Web, se moquer de l'utilisateur autant et de la manière la plus réaliste possible). Bien qu’elle n’ait pas constaté d’améliorations spectaculaires sur le plan des performances des tests (le principal problème qui a motivé l’intérêt pour la preuve de concept initiale), l’équipe a conclu positivement :