JavaScript Testing Part- 2

In this I will be testing a REST API that I have created , the GitHub link for that is SIDD58. You can clone the repository and follow readme.md

Please visit Part-1 of this Series before proceeding this one to get general understanding of how Jest works. Also make sure you have basic understanding of REST API.

Step 1: Run npm install command and save this as development dependecy as because it is for Testing Environment. Installing jest (javascript testing framework) and supertest (for testing HTTP request)

Why use supertest instead of Postman ?

Unlike Postman which is used for manual testing , supertest can be used for automated testing and can be easily integrated with CI/CD pipeline and secondly it does not require server running to test (as it injects request directly into the app) and it is fast because of no network overhead.

Reason: supertest directly injects requests into express app memory(which is just router that listens and sends response) without binding it to port. No need of server or network.

Why use Postman instead of supertest ?

Postman performs end to end testing. Tests can fail due to real world scenarios like firewall, load balancer issues, security & CORS issue ,API gateway issues, interaction with real Database (not mock database). It tests the entire API infrastructure that is also why it needs a server running to test.

Step 2: Set your test environment to node and set the script to jest with coverage and watchAll option turned on.

Why to set test Environment?

By default jest uses jsdom thatr simulates browser like Environment that is you will have access to things like window, document, localstorage in your environment.

If you set your environment to node only then you can have access to things like require(‘fs’) ,process.env.

Hence, it is necessary to set the environment to node. Make these changes in package.json file.

Step 3: Here app is the express application [i.e const app=express()].

1. In Node JS every file is treated as a module.

2. module object is automatically created for each file in Node JS and it refers to file itself .

3. module.exports property of object tells what a module exports to other files.

4. main module term refers to module/file that was first executed when the Node.js process was started. example node server.js

5. require.main is property that points to main module object.

if the current file is the main module then it starts the server otherwise if current file is not main module then it exports app object

Why export app object ?

We are exporting app object so that tools like supertest can use this to simulate HTTP requests and we can do HTTP request testing.

Step 4: Create a folder tests within which you create api.test.js and input the code mentioned in the image.

1. describe block : describe block is used to group related tests together and it can be nested, so that we can organize it effectively . it is used to group related tests together. it’s syntax is like describe(name, fn) where name is string and fn is the function.
2. it or test block: it describes the single test case within which you describe the behavior you are testing. ‘it’ is an alias for ‘test’. It’s syntax is like test(name, fn)where name is string and fn is the function.
3. In supertest(), we pass the Express app instance (imported from server.js). This allows us to make HTTP requests directly to the app without needing to start the server. We can then use it just like we would have use app.get('/') to get the response in our application.
4. expect(res.statusCode).toEqual(200) checks that the HTTP status code of the response is 200, meaning the request was successful.
5. We need to use here async and await syntax , as HTTP request are asynchronous . Without await , test assertions might run before the requests complete leading to inaccurate results.

Step 5: Running npm run test would show the following results. Observe here how describe statement has organized our test cases.

You can review the rest of the api.test.js file in GitHub. it includes the implementation of testing other endpoints.