Hello everyone! I was inspired to write this article by my students and mentees. I often recommend they learn as soon as they get comfortable with the test automation process on . Let’s see what the traits of using TypeScript in your test automation framework in terms of REST API testing are… TypeScript JavaScript You can find the full code of a test project . here TypeScript Let’s not get too deep into what is and how it is different than and state the important thing - . But, quite important too - it depends on ( platform) directly. TypeScript JavaScript it’s programming language the JavaScript Node.js is presented as a package, so I look at this just as with some cool features. TypeScript Node.js JavaScript To learn more about the language itself and what it has to offer - please visit while we are going to talk about its features in terms of test automation… the official website Project setup Let’s go through the test automation project creation process on : TypeScript Create a project. Node.js npm init -y Install the package. TypeScript npm i typescript Generate a default configuration for the project - . TypeScript tsconfig.json npx tsc --init The command above will generate a default config file, but I recommend shortening it a lot to something like : this { "compilerOptions": { "baseUrl": "./", "module": "esnext", "target": "esnext", "sourceMap": false, "moduleResolution": "node", "allowJs": true, "skipLibCheck": true, "resolveJsonModule": true, "allowSyntheticDefaultImports": true, "paths": { "*": ["./*"] } } } This config contains the required minimum: uses the latest version, EcmaScript makes JSON imports available, lets you use absolute path in imports. You can extend your config using . official documentation Tools selection You can use any tool that the ecosystem has to offer, but in my experience - most of the choose for a couple of good reasons: Node.js engineers who work with TypeScript Jest great community support (updates, answers, docs, code examples), flexible configuration. Previously, I had fun using + to set up the core of the project, but now I'm sticking to too, as it contains both a test runner & assertion library. Mocha Chai Jest, seems to be the most popular HTTP client, so I suggest this is your pick too. Axios Can't say that you are forced to use this for your setup, but I'm saying that it's the usual thing when you look through the projects. Now, simply install these packages as dependencies: npm i jest axios Type collections Some packages (like ) contain types inside, but don't. Also, requires a package along with to work properly - the first one enables features & second lets you use . Axios TypeScript Jest & Mocha Jest ts-jest @types/jest TypeScript IntelliSense So keep in mind - if you don't have autocomplete feature when you're trying to use some of the packages - you're probably missing type declarations. Let's install -related extensions (packages) as well: TypeScript npm i ts-jest @types/jest Configuration requires a config preset, so you must declare it in your config (or ) file: Jest ts-jest package.json { "jest": { "preset": "ts-jest" } } If you're planning to , you'd need to adjust your config as well: use absolute path within a project { "jest": { "preset": "ts-jest", "moduleDirectories": [ "node_modules", "<rootDir>" ] } } This config allows you to run tests with a simple command... jest So, configure your script in to be: test package.json { "scripts": { "test": "jest" } } And then run your tests any time with or command. npm test npm run test I also recommend you install if you are a user - it allows you / desired tests/suites with just one click. In it's a built-in feature. a Jest Runner extension Visual Studio Code run debug WebStorm, Custom types The main feature that introduces into REST API testing is... , of course! TypeScript types You can declare what your request & response body should look like, i.e., , and etc. key names value types Let's take a server as an example - we can write down its request body payload for endpoint as a type: Paysis /auth export type AuthRequestBody = { login: string password: string } And same for the response body - what server should send to our request: export type AuthResponseBody = { token?: string message?: string } Since there'd be a different payload for success/failure scenarios - you can mark keys as "optional" via the “ character. ?” Once it's done - you can use these types to compose requests and verifications in your tests... Request In , you can say what body you are sending via the request config: Axios const payload: AxiosRequestConfig<AuthRequestBody> = { method: 'post', url: '/auth', data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, } in means exactly that ☝️ AuthRequestBody AxiosRequestConfig<AuthRequestBody> It means you'll be forced to use the payload that matches the provided type in object. If you forget to set some required fields or set some excessive ones - you'll see an error. AuthRequestBody data Response The same thing can be done about response as well: const response: AxiosResponse<AuthResponseBody> = await client.request(payload) It will add autocomplete to the object, so you'd be able to reach or fields. response.data response.data.token response.data.message Advanced tools Apart from the simple stuff above, it's also possible to . It lets you not check every single key in a response body to see if it matches the schema but . generate a JSON schema from your custom types check the whole payload So the idea is: Generate a from custom types. JSON schema Use a custom matcher to validate the response body. toMatchSchema Pretty cool stuff, but keep in mind that your tests might become flaky after these changes - it happens when some additional fields appear, so you'd need to update the schema regularly. Conclusion setup might be tricky, especially if it's your first time, but it's worth it! TypeScript If you cover your input & output data with types - there’s no way you’d make a typo or some other syntax error when you parse these objects. It saves you from simple mistakes and lets you see the structure of your requests right in your code, so you don’t have to open any (like ) and look for the request you need to see what body it request/responds with. HTTP collection Postman Let me know about your experience and what you think about it.
