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 .
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 -
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…
Passons en revue le processus de création d'un projet d'automatisation de test sur TypeScript :
Créez un projet Node.js.
npm init -y
Installez le package TypeScript .
npm i typescript
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 :
Vous pouvez étendre votre configuration en utilisant la documentation officielle .
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 :
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
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
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
.
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.
La principale fonctionnalité introduite par TypeScript dans les tests de l'API REST est...
Vous pouvez déclarer à quoi votre corps de requête et de réponse devrait ressembler, c'est-à-dire,
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...
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.
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
.
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 :
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.
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.