Stratégies d'automatisation des tests utiles à connaître dès maintenant

Dans les applications web modernes, l'automatisation des tests est cruciale pour la qualité et la maintenabilité, mais de nombreux développeurs ont du mal à écrire du code de test car ils manquent d'expérience dans ce domaine.
Ce livre s'adresse aux développeurs front-end qui écrivent du code de test pour la première fois et explique non seulement la méthode de base d'écriture de code de test, mais aussi la méthode d'écriture de code de test adaptée à chaque situation et comment utiliser divers outils, avec de nombreux exemples.
Il comprend notamment des exemples créés avec TypeScript et Next.js, vous permettant d'acquérir les connaissances et le savoir-faire pratiques les plus récents.
La version coréenne a été encore améliorée par l'ajout de tests de composants d'interface utilisateur et de tests E2E dans GitHub Actions en annexes.

Les modifications de code ne sont pas seulement nécessaires lors du développement de nouvelles fonctionnalités.
Le développement front-end moderne repose sur de nombreuses bibliothèques ; la mise à jour de ces bibliothèques nécessite donc également de modifier votre code.
Bien sûr, si vous utilisez Dependabot, celui-ci vérifiera automatiquement les vulnérabilités pouvant survenir lors de la mise à jour des bibliothèques dépendantes et créera une demande d'extraction.
Cependant, il ne faut pas supposer que Defenderbot filtrera toutes les vulnérabilités.
Si vous avez écrit du code de test, vous devriez établir une règle telle que « les mises à jour mineures peuvent être fusionnées si les tests réussissent ».

--- p.6

La refactorisation peut être effrayante lorsque votre projet publié ne comporte aucun code de test.
Vous devriez commencer par organiser les fonctionnalités publiées dans une liste.
Une fois le problème résolu, rédigez des tests de régression pour vérifier qu'aucun défaut ne survient avant ou après la modification.
Une fois les tests de régression rédigés, vous pouvez entamer la refactorisation en toute confiance.

--- p.23

Plus un test est similaire à l'environnement d'exécution réel, plus il est reproductible.
Cependant, à mesure que la reproductibilité augmente, le temps d'exécution peut devenir trop long ou la configuration de l'environnement peut devenir difficile.
Un cas typique se présente lorsque vous devez traiter des données obtenues à partir d'une API web, et que, lors de l'obtention de ces données, l'opération échoue parfois pour des raisons telles qu'une erreur réseau.
Lorsque vous utilisez des API web, vous devez tester non seulement le « cas de succès », mais aussi le « cas d'échec ».
Si l'opération réussit, vous pouvez la tester en connectant le serveur API Web réel à l'environnement de test.
Il n'est pas correct d'ajouter du code au serveur d'API Web pour tester les cas de défaillance.
De plus, il est impossible d'ajouter une implémentation de test à l'API web d'un service externe.

--- p.53

La couverture est un indicateur quantitatif qui peut être mesuré objectivement.
Selon le projet, elle sert également de norme de qualité à respecter.
Par exemple, il peut être utilisé pour créer un pipeline tel que « Si la couverture de la branche n'est pas supérieure à 80 %, elle ne passe pas l'intégration continue ».
(...) La couverture est utilisée comme déclencheur pour examiner si des tests doivent être ajoutés à un fichier spécifique.
Il est également utile pour trouver du code dupliqué qui a passé ESLint mais qui subsiste.
Nous recommandons de consulter les rapports de couverture afin de déterminer s'il existe des domaines qui n'ont pas été suffisamment testés avant leur mise en production.

--- p.132

Le module d'exécution de tests de Storybook convertit les histoires en tests exécutables.
Les scénarios convertis en tests sont exécutés dans Jest et Playrite.
Cette fonctionnalité peut être utilisée pour effectuer des tests de fumée sur le Storybook, ainsi que pour vérifier si la fonction de lecture que nous avons examinée précédemment s'est déroulée normalement et s'il existe des violations d'accessibilité ; elle peut donc également être utilisée pour tester les composants d'interface utilisateur.

--- p.202

Les tests E2E côté client permettent de tester au plus près de l'application réelle, car ils peuvent utiliser un navigateur.
Il est idéal pour les situations où vous devez utiliser des API spécifiques au navigateur ou effectuer des tests tout en déplaçant l'écran.
(...) L'élément le plus important dans les tests E2E est de définir clairement l'objectif de ce qui doit être testé.
L'application proprement dite se connecte à un serveur de base de données ou à un service de stockage externe.
Dans les tests E2E, un critère important est la capacité de l'ensemble de la structure, y compris ces systèmes, à reproduire fidèlement une situation réaliste.

--- p.239