Tester une application React

Test unitaire de composants avec Enzyme

$ yarn init -y 
$ yarn add -D parcel-bundler 
$ yarn add react react-dom 

<div id="app"></div> 
<script src="../src/index.js"></script> 

import React, { useState, useCallback } from 'react' 
 
export const ContactForm = ({ contact, updateContact }) => { 
 const [name, setName] = useState(contact.name) 
 const onChangeName = useCallback( 
   event => { 
     setName(event.target.value) 
   }, 
   [setName], 
 ) 
 const onSubmit = useCallback(event => { 
   event.preventDefault() 
   if (name !== '') { 
     updateContact({ name }) 
   } 
 }) 
 
 return ( 
   <form onSubmit={onSubmit}> 
     <label> 
       Name: 
       <input name="name"...

Tester le store Redux et les sagas avec Redux Saga Test Plan

Tester le store Redux d’une application peut très bien se faire sans bibliothèque externe. Après tout, un reducer n’est qu’une simple fonction n’ayant aucun effet de bord, les créateurs d’action également, ainsi que les sélecteurs. Seules les sagas pourraient poser un peu plus de difficultés, mais en sachant qu’elles ne sont que des fonctions génératrices, on pourrait tout de même s’en sortir. Néanmoins, ces tests ne seraient pas réellement pertinents.

Dans cette section, nous allons voir comment grâce à Redux Saga Test Plan, on peut écrire des tests sur un store entier (ou sur un morceau de store ou service, comme nous en avons écrit dans les chapitres Concevoir une application avec Redhux et Gérer les effets de bord avec Redux-Saga), en le considérant comme une boîte noire. Autrement dit, nous vérifierons que lorsque l’on dispatche une action :

Comme exemple accompagnant cette section, nous allons repartir de l’exemple précédent avec son ContactForm, en y ajoutant un appel à l’API de JSON Placeholder, que nous avons vue à plusieurs reprises, pour initialiser le nom du contact.

Notre store Redux sera extrêmement semblable à ce que nous avons vu dans les chapitres sur Redux et Redux Saga (dans un seul fichier pour aller à l’essentiel). 

Il gère trois actions, une pour demander la récupération du contact, et deux pour gérer les cas de succès et d’erreur :

export const actionTypes = { 
 GET_CONTACT: 'GET_CONTACT', 
 GET_CONTACT_SUCCESS: 'GET_CONTACT_SUCCESS', 
 GET_CONTACT_FAILURE: 'GET_CONTACT_FAILURE', 
} 
 
export const actions = { 
 getContact: () => ({ type: actionTypes.GET_CONTACT }), 
 getContactSuccess: contact => ({ 
   type: actionTypes.GET_CONTACT_SUCCESS, 
   payload: contact, ...

En conclusion

Ainsi se clôt notre exploration du test d’une application React. Nous aurions pu aborder beaucoup d’autres sujets et manières de tester une application. Parmi les autres outils en vogue, citons par exemple Cypress (https://www.cypress.io) particulièrement adapté pour des tests end-to-end, qui vont jusqu’à lancer un navigateur pour ouvrir l’application testée, effectuer une série d’actions, pour vérifier que les éléments attendus sont présents sur la page.

Le sujet des tests front-end n’est en rien spécifique à React. D’ailleurs, toute la section consacrée à Redux Saga Test Plan pourrait s’appliquer à n’importe quelle bibliothèque de rendu, du moment que l’on utilise Redux et Redux Saga (ce qu’il est possible de faire avec Angular ou Vue par exemple). Mais il est tout de même intéressant de voir les différentes possibilités qui s’offrent à nous lorsqu’on souhaite tester une application dans un cadre professionnel, ou pour une application que l’on souhaite stable au fil de ses versions.

Certains projets ont pour philosophie de mettre le moins de logique possible dans les composants React, au point de réduire leur fonction au simple affichage de données. Cela est généralement une bonne pratique et justifie...