paint-brush
TypeScript vs JavaScript dans le test automatisé de l'API RESTpar@bormando
3,329 lectures
3,329 lectures

TypeScript vs JavaScript dans le test automatisé de l'API REST

par Dmitrii Bormotov6m2023/08/04
Read on Terminal Reader

Trop long; Pour lire

TypeScript est un langage de programmation présenté sous forme de package dans l'écosystème Node.js. En utilisant ce package, vous pouvez : 1. Effectuez des importations concises (absolues) dans votre projet. 2. Créez des types personnalisés pour vos charges utiles de demande et de réponse. 3. Utilisez les fonctionnalités d'intellisense et de vérification de type pour faire moins d'erreurs de syntaxe dans votre code. Les types personnalisés agissent également comme une documentation pour vos données de charge utile - vous n'aurez plus à vérifier auprès de vos collections/outils externes pour cela !
featured image - TypeScript vs JavaScript dans le test automatisé de l'API REST
Dmitrii Bormotov HackerNoon profile picture
0-item

Bonjour à tous!


J'ai été inspiré pour écrire cet article par mes étudiants et mentorés. Je leur recommande souvent d'apprendre TypeScript dès qu'ils se familiarisent avec le processus d'automatisation des tests sur JavaScript . Voyons quelles sont les caractéristiques de l'utilisation de TypeScript dans votre infrastructure d'automatisation des tests en termes de test d'API REST…


Vous pouvez trouver le code complet d'un projet de test ici .

Manuscrit

N'allons pas trop loin dans ce qu'est TypeScript et en quoi il est différent de JavaScript et énonçons la chose importante - c'est le langage de programmation . Mais, assez important aussi - cela dépend directement de JavaScript (plate-forme Node.js ).


TypeScript est présenté sous la forme d'un package Node.js , donc je le considère comme du JavaScript avec quelques fonctionnalités intéressantes.


Pour en savoir plus sur le langage lui-même et ce qu'il a à offrir - veuillez visiter le site officiel pendant que nous parlerons de ses fonctionnalités en termes d'automatisation des tests…

Configuration du projet

Passons en revue le processus de création d'un projet d'automatisation de test sur TypeScript :


  1. Créez un projet Node.js.

    npm init -y

  2. Installez le package TypeScript .

    npm i typescript

  3. Générez une configuration TypeScript par défaut pour le projet - tsconfig.json .

    npx tsc --init


La commande ci-dessus générera un fichier de configuration par défaut, mais je recommande de le raccourcir beaucoup à quelque chose comme ceci :


 { "compilerOptions": { "baseUrl": "./", "module": "esnext", "target": "esnext", "sourceMap": false, "moduleResolution": "node", "allowJs": true, "skipLibCheck": true, "resolveJsonModule": true, "allowSyntheticDefaultImports": true, "paths": { "*": ["./*"] } } }


Cette configuration contient le minimum requis :


  • utilise la dernière version d'EcmaScript ,
  • rend disponible les importations JSON,
  • vous permet d'utiliser un chemin absolu dans les importations.


Vous pouvez étendre votre configuration en utilisant la documentation officielle .


Sélection d'outils

Vous pouvez utiliser n'importe quel outil proposé par l'écosystème Node.js , mais d'après mon expérience, la plupart des ingénieurs qui travaillent avec TypeScript choisissent Jest pour plusieurs bonnes raisons :


  • grand soutien de la communauté (mises à jour, réponses, docs, exemples de code),
  • configuration souple.


Auparavant, je m'amusais à utiliser Mocha + Chai pour configurer le cœur du projet, mais maintenant je m'en tiens également à Jest , car il contient à la fois un testeur et une bibliothèque d'assertions.


Axios semble être le client HTTP le plus populaire, donc je suggère que c'est aussi votre choix.


Je ne peux pas dire que vous êtes obligé de l'utiliser pour votre configuration, mais je dis que c'est la chose habituelle lorsque vous parcourez les projets.


Maintenant, installez simplement ces packages en tant que dépendances :

npm i jest axios

Collections de types

Certains packages (comme Axios ) contiennent des types TypeScript à l'intérieur, mais pas Jest & Mocha . De plus, Jest nécessite un package ts-jest avec @types/jest pour fonctionner correctement - le premier active les fonctionnalités TypeScript et le second vous permet d'utiliser IntelliSense .


Gardez donc à l'esprit - si vous ne disposez pas de la fonction de saisie semi-automatique lorsque vous essayez d'utiliser certains packages - il vous manque probablement des déclarations de type.


Installons également les extensions (packages) liées à TypeScript :

npm i ts-jest @types/jest

Configuration

Jest nécessite un préréglage de configuration ts-jest , vous devez donc le déclarer dans votre fichier de configuration (ou package.json ) :


 { "jest": { "preset": "ts-jest" } }


Si vous envisagez d' utiliser un chemin absolu dans un projet , vous devez également ajuster votre configuration :


 { "jest": { "preset": "ts-jest", "moduleDirectories": [ "node_modules", "<rootDir>" ] } }


Cette configuration vous permet d'exécuter des tests avec une simple commande... jest


Alors, configurez votre script de test dans package.json pour qu'il soit :


 { "scripts": { "test": "jest" } }


Ensuite, exécutez vos tests à tout moment avec la commande npm test ou npm run test .


Tests en cours


Je vous recommande également d'installer une extension Jest Runner si vous êtes un utilisateur de Visual Studio Code - elle vous permet d'exécuter / déboguer les tests/suites souhaités en un seul clic. Dans WebStorm, c'est une fonctionnalité intégrée.


Exécutez et déboguez des tests en un seul clic !

Types personnalisés

La principale fonctionnalité introduite par TypeScript dans les tests de l'API REST est... les types , bien sûr!


Vous pouvez déclarer à quoi votre corps de requête et de réponse devrait ressembler, c'est-à-dire, noms de clé , types de valeur et etc.


Prenons un serveur Paysis comme exemple - nous pouvons écrire sa charge utile de corps de requête pour le point de terminaison /auth en tant que type :


 export type AuthRequestBody = { login: string password: string }


Et pareil pour le corps de la réponse - quel serveur doit envoyer à notre requête :


 export type AuthResponseBody = { token?: string message?: string }


Puisqu'il y aurait une charge utile différente pour les scénarios de réussite/échec - vous pouvez marquer les clés comme "facultatives" via le " ?" personnage.


Une fois que c'est fait - vous pouvez utiliser ces types pour composer des requêtes et des vérifications dans vos tests...

Demande

Dans Axios , vous pouvez dire quel corps vous envoyez via la configuration de la requête :


 const payload: AxiosRequestConfig<AuthRequestBody> = { method: 'post', url: '/auth', data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, }


AuthRequestBody dans AxiosRequestConfig<AuthRequestBody> signifie exactement cela ☝️

Cela signifie que vous serez obligé d'utiliser la charge utile qui correspond au type AuthRequestBody fourni dans l'objet data . Si vous oubliez de définir certains champs obligatoires ou si vous en définissez trop, vous verrez une erreur.

Réponse

La même chose peut être faite à propos de la réponse :


 const response: AxiosResponse<AuthResponseBody> = await client.request(payload)


Il ajoutera la saisie semi-automatique à l'objet response.data , afin que vous puissiez atteindre les champs response.data.token ou response.data.message .

Outils avancés

Outre les éléments simples ci-dessus, il est également possible de générer un schéma JSON à partir de vos types personnalisés . Cela vous permet de ne pas vérifier chaque clé dans un corps de réponse pour voir si elle correspond au schéma, mais de vérifier l'ensemble de la charge utile .


Donc l'idée c'est :


  1. Générez un schéma JSON à partir de types personnalisés.
  2. Utilisez un matcher personnalisé toMatchSchema pour valider le corps de la réponse.


Des trucs plutôt cool, mais gardez à l'esprit que vos tests peuvent devenir instables après ces changements - cela se produit lorsque des champs supplémentaires apparaissent, vous devez donc mettre à jour le schéma régulièrement.

Conclusion

La configuration de TypeScript peut être délicate, surtout si c'est votre première fois, mais ça vaut le coup !


Si vous couvrez vos données d'entrée et de sortie avec des types - il n'y a aucun moyen que vous fassiez une faute de frappe ou une autre erreur de syntaxe lorsque vous analysez ces objets. Il vous évite de simples erreurs et vous permet de voir la structure de vos requêtes directement dans votre code, vous n'avez donc pas besoin d'ouvrir une collection HTTP (comme Postman ) et de rechercher la requête dont vous avez besoin pour voir quel corps il demande/répond avec.


Faites-moi part de votre expérience et de ce que vous en pensez.