demo4 et demo5 peut être essayé de parcourir npm run test:demo4–5. De cette manière, une véritable demande de données est effectuée. Ici, axios le proxy sera utilisé pour transmettre les demandes de données internes au port du serveur spécifié. Par conséquent, le serveur est également démarré localement et le test est effectué en spécifiant les données de requête et de réponse liées au correspondant. path. Si les données demandées sont incorrectes, les données de réponse associées ne correspondront pas normalement. Par conséquent, la demande renverra directement 500. Si les données de réponse renvoyées sont incorrectes, elles seront également capturées lors de l’assertion. Dans le jest-mock-server bibliothèque, nous devons d’abord spécifier trois fichiers qui correspondent aux trois cycles de vie que chaque fichier de test unitaire doit exécuter avant le démarrage. Jest le test est exécuté avant les trois cycles de vie et les trois cycles de vie sont exécutés après le Jest l’essai est terminé. Les trois fichiers que nous devons spécifier sont les setupFiles, globalSetupet globalTeardown éléments de configuration du jest.config.js fichier de configuration.
Nous allons d’abord commencer par setupFiles. En plus d’initialiser JSDOMnous devons également utiliser le proxy par défaut de axios. Parce que la solution adoptée est d’utiliser le proxy de axios pour transmettre les demandes de données. Par conséquent, il est nécessaire de placer la valeur proxy au premier plan du test unitaire.
Une fois que nous avons configuré le fichier ci-dessus dans letest/config dossier, nous devons y ajouter deux autres fichiers qui sont globalSetup et globalTeardown . Ces deux fichiers font référence aux opérations effectuées avant le Jest le test unitaire commence et une fois tous les tests terminés. Nous mettons les opérations de démarrage et d’arrêt du serveur dans ces deux fichiers.
Veuillez noter que le fichier exécuté dans ces deux fichiers est un fichier indépendant distinct.
contexce qui n’a rien à voir avec lecontexde tout test unitaire incluant le fichier spécifié par l’élément de configuration setupFiles. Par conséquent, toutes les données ici sont soit spécifiées dans le fichier de configuration, soit transmises entre les ports du serveur via le réseau.
Pour les informations sur le port de configuration et le nom de domaine, placez-les directement dans le globals champ dans jest.config.js. Pour le debug élément de configuration, il est recommandé de l’utiliser conjointement avec test.only.
Maintenant, on peut suggérer pourquoi le serveur ne devrait pas être démarré et arrêté dans le beforeAll et afterAll cycles de vie de chaque fichier de test unitaire. Par conséquent, j’ai essayé cette solution. Dans cette solution, pour chaque fichier de test, le serveur est démarré puis arrêté. Cette solution est donc relativement longue. Mais en théorie, cette solution est raisonnable. Après tout, il est vrai que l’isolation des données est nécessaire. Mais il y a un problème quand afterAll est fermé. Cela ne ferme pas réellement l’occupation du serveur et du port car le close la méthode est appelée lorsque le node le serveur est fermé. QuandafterAll est fermé, il vient d’arrêter de traiter la demande mais le port est toujours occupé. Lorsque le deuxième fichier de test unitaire est démarré, une exception sera levée indiquant que le port est utilisé. Même si j’ai essayé quelques solutions, elles ne sont pas idéales car parfois le port est encore occupé. Surtout quand le node est exécuté pour la première fois après sa mise sous tension, la probabilité d’anomalie est relativement élevée. L’effet n’est donc pas très satisfaisant. Au final, le schéma d’isolement complet est adopté. Pour des problèmes connexes spécifiques, veuillez vous référer à ceci lien.
Puisque nous adoptons une solution complètement isolée, il n’y a que deux options lorsque nous voulons transmettre les données de requête et de réponse pour la requête de test. Les deux solutions sont soit au démarrage du serveur toutes les données sont spécifiées dans le test/config/global-setup.js Le fichier ou les données sont transmis via le réseau lorsque le serveur est en cours d’exécution, le chemin est spécifié et la demande réseau du chemin transportera les données et la demande de données sera spécifiée lors de la fermeture du serveur. Par conséquent, les deux options sont prises en charge ici. Je pense qu’il est plus approprié de spécifier vos propres données dans chaque fichier de test unitaire, voici donc seulement un exemple de spécification des données à tester dans le fichier de test unitaire. Concernant les données à tester, un DataMapper type est spécifié pour réduire les exceptions causées par des erreurs de type. Par conséquent, deux ensembles de données sont illustrés ici. De plus, les expressions régulières sont prises en charge lors de la correspondance query et data. La structure du DataMapper le type est relativement standard.
Dans les deux tests unitaires ci-dessous, les données à tester sont spécifiées dans beforeAll. Noter que beforeAll renvoie setSuitesData(data) car le test unitaire est exécuté une fois les données définies et la réponse réussie, suivi de la demande normale et de la réponse indiquant si le test d’assertion est correct.
