Comprendre la configuration Jest (cloned)
Les tests en React
Pour les tests de composants React, le framework utilisé est Testing Library et l'outil de lancement des tests est Jest. Ces deux outils ne sont pas spécifiques à React, mais ils ont une implémentation React ou un fonctionnement compatible avec React.
Le principe pour Ă©crire un test est le suivant :
- Rendre une suite de composant : Render
- Récupérer des éléments du DOM (ou vérifier leur présence) : Queries (par défaut, utilisez getByRole, celui à bannir est getByDataTestId.)
- Interagir avec le DOM (cliquer sur un bouton) > User interaction (utilisez impérativement userEvent et non fireEvent.)
- Attendre un résultat > Expect · Jest et Appearance and Disappearance
Pour allez plus loin,voici plusieurs liens :
Donc ici, si l'on suit cette logique, nous n'avons pas besoin de mocker nos hooks, utils, ou autres, car nos composants sont construits comme sur le navigateur. On teste directement toute une page ! On peut bien sûr les découper pour spécialiser nos tests. Vous allez me dire : c'est bien beau tout ça, mais comment je fais pour tester un composant qui fait un appel d'API REST et/ou GraphQL ?
La solution est MSW v1 :
Cette petite librairie permet de faire des mocks d'API mais intégrée facilement aux tests (notamment pour les CI). TrÚs facile à appréhender, elle permet d'utiliser Axios, Fetch ou Apollo, ou autre, sans aucune différence et simule réellement un appel avec un delay, un status, etc.
FASST testings
Nos projets sont composés de trois parties, chacune nécessitant sa propre configuration : app, server, views. Chaque configuration se trouve dans le dossier portant sont nom, exemple : app/jest.config.mjs
La configuration app et views est similaire : elles sont sur un environnement JSDOM, alors que la partie server est testée dans un environnement Node. Chaque partie génÚre la couverture de code des fichiers testés dans un sous-dossier du dossier /coverage/, (si aucun tests n'est effectué sur un fichier, il ne sera pas présent dans le tableau récapitulatif).
Il y a donc trois scripts disponibles pour lancer chaque partie, ainsi qu'un script pour tous les lancer et un script pour le lancement de CI :
"test": "yarn test:server && yarn test:app && yarn test:views",
"test:app": "yarn jest --config=app/jest.config.mjs",
"test:views": "yarn jest --config=views/jest.config.mjs",
"test:server": "cross-env NODE_OPTIONS=--experimental-vm-modules yarn jest --config=server/jest.config.mjs",
"test:ci": "yarn test:server --ci && yarn test:app --ci && yarn test:views --ci",Seules les commandes test:app, test:views et test:server ci-dessus est compatibles avec la syntaxe du CLI de jest. Les commandes test et test:ci ne le sont pas. Par exemple, pour lancer un fichier spécifique : yarn test:views MaSuperView
App and views
Pour les parties app et views, la configuration utilise un fichier de setup et un fichier de setupAfterEnv :
setupFiles: ['<rootDir>/tests/__utils__/init-app.mjs'],
setupFilesAfterEnv: ['<rootDir>/tests/__utils__/init-app-after-env.mjs'],- Le premier permet de configurer les clefs process.env nécessaires et d'ajouter à l'env JSDOM whatwg-fetch. (Fetch est devenu natif sur les navigateurs et nodejs 18+ , mais toujours pas en JSDOM, il est donc nécessaire de le rajouter manuellement).
- Le second permet de configuré MSW v1 qui interceptera tous les appels d'API partant de vos composants. Certaines configuration (comme l'appel de récupération du token) sont nécessaires pour tous les tests et sont donc directement placées dans ce fichier. Il est possible d'en rajouter suivant les besoins de votre projet.
Providers
Les composants utilisent des hooks ou un context fourni par des providers des composants parents (pouvant ĂȘtre situĂ©s Ă diffĂ©rents endroits). Pour les tests, il est nĂ©cessaire de les fournir afin que le composant enfant qui les utilise puisse ĂȘtre construit et rendu. Pour cela, les providers sont dĂ©coupĂ©s dans le fichier /app/index.js et se trouvent dans le dossier /providers. un nouveau composant (appelĂ© <ProjectProviders />), permettant dâinstancier tous les providers globaux au projet, est donc crĂ©Ă©.
Le ProjectProviders est ensuite appelĂ© au niveau des tests via le composant surcouche situĂ© dans /test/__custom__/TestProviders.jsx (ce composant, pour le moment, ne fait rien mais peut ĂȘtre surchargĂ© pour avoir des configurations de providers plus spĂ©cifiques aux tests) qui sera ensuite ajoutĂ© en tant que wrapper au moment de rendre le composant dans les tests :
render(<MyAwesomeComponentThatUseSomeContext/>, {
wrapper: ({ children }) => <TestsProviders>{children}</TestsProviders>,
});Maintenant que notre composant est rendu avec les différents providers, il peut utiliser les informations du Process.
Server
La configuration server utilise un fichier de setup permettant de vérifier aprÚs chaque fichier de tests si la connexion mongo a bien été fermée et si les models présents ont bien été supprimés pour ne pas impacter les tests suivants.
setupFiles: ['<rootDir>/tests/__utils__/init-server.mjs'],Il est tout Ă fait possible de changer cela pour ne pas avoir Ă faire de start and stop Ă chaque test, mais de garder l'environnement ouvert pour toute lâexĂ©cution des tests (mais attention, tous vos tests s'impacteront entre eu car ils utiliseront les mĂȘmes donnĂ©es). Pour cela, il faut passer par des configurations globales de setup et teardown : https://jestjs.io/fr/docs/29.6/configuration#globalsetup-string