Bonjour à tous! J'ai été inspiré pour écrire cet article par mes étudiants et mentorés. Je leur recommande souvent d'apprendre dès qu'ils se familiarisent avec le processus d'automatisation des tests sur . 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… TypeScript JavaScript Vous pouvez trouver le code complet d'un projet de test . ici Manuscrit N'allons pas trop loin dans ce qu'est et en quoi il est différent de et énonçons la chose importante - . Mais, assez important aussi - cela dépend directement de (plate-forme ). TypeScript JavaScript c'est langage de programmation le JavaScript Node.js est présenté sous la forme d'un package , donc je le considère comme avec quelques fonctionnalités intéressantes. TypeScript Node.js du JavaScript Pour en savoir plus sur le langage lui-même et ce qu'il a à offrir - veuillez visiter pendant que nous parlerons de ses fonctionnalités en termes d'automatisation des tests… le site officiel Configuration du projet 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 par défaut pour le projet - . TypeScript 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 , mais d'après mon expérience, la plupart des choisissent pour plusieurs bonnes raisons : Node.js ingénieurs qui travaillent avec TypeScript Jest grand soutien de la communauté (mises à jour, réponses, docs, exemples de code), configuration souple. Auparavant, je m'amusais à utiliser + pour configurer le cœur du projet, mais maintenant je m'en tiens également à , car il contient à la fois un testeur et une bibliothèque d'assertions. Mocha Chai Jest semble être le client HTTP le plus populaire, donc je suggère que c'est aussi votre choix. Axios 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 ) contiennent des types à l'intérieur, mais pas . De plus, nécessite un package avec pour fonctionner correctement - le premier active les fonctionnalités et le second vous permet d'utiliser . Axios TypeScript Jest & Mocha Jest ts-jest @types/jest TypeScript 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 nécessite un préréglage de configuration , vous devez donc le déclarer dans votre fichier de configuration (ou ) : Jest ts-jest package.json { "jest": { "preset": "ts-jest" } } Si vous envisagez d' , vous devez également ajuster votre configuration : utiliser un chemin absolu dans un projet { "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 dans pour qu'il soit : de test package.json { "scripts": { "test": "jest" } } Ensuite, exécutez vos tests à tout moment avec la commande ou . npm test npm run test Je vous recommande également d'installer si vous êtes un utilisateur - elle vous permet / les tests/suites souhaités en un seul clic. Dans c'est une fonctionnalité intégrée. une extension Jest Runner de Visual Studio Code d'exécuter déboguer WebStorm, Types personnalisés La principale fonctionnalité introduite par dans les tests de l'API REST est... , bien sûr! TypeScript les types Vous pouvez déclarer à quoi votre corps de requête et de réponse devrait ressembler, c'est-à-dire, , et etc. noms de clé types de valeur Prenons un serveur comme exemple - nous pouvons écrire sa charge utile de corps de requête pour le point de terminaison en tant que type : Paysis /auth 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 , vous pouvez dire quel corps vous envoyez via la configuration de la requête : Axios const payload: AxiosRequestConfig<AuthRequestBody> = { method: 'post', url: '/auth', data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, } dans signifie exactement cela ☝️ AuthRequestBody AxiosRequestConfig<AuthRequestBody> Cela signifie que vous serez obligé d'utiliser la charge utile qui correspond au type fourni dans l'objet . Si vous oubliez de définir certains champs obligatoires ou si vous en définissez trop, vous verrez une erreur. AuthRequestBody data 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 , afin que vous puissiez atteindre les champs ou . response.data response.data.token response.data.message Outils avancés Outre les éléments simples ci-dessus, il est également possible de . 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 . générer un schéma JSON à partir de vos types personnalisés de vérifier l'ensemble de la charge utile Donc l'idée c'est : Générez un à partir de types personnalisés. schéma JSON Utilisez un matcher personnalisé pour valider le corps de la réponse. toMatchSchema 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 peut être délicate, surtout si c'est votre première fois, mais ça vaut le coup ! de TypeScript 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 (comme ) et de rechercher la requête dont vous avez besoin pour voir quel corps il demande/répond avec. collection HTTP Postman Faites-moi part de votre expérience et de ce que vous en pensez.
