REST API automation using Postman, Newman and Jenkins

Welcome! My name is Alina and I am the leader of QA 🙂

In this article, I would like to share my experience in automating REST APIs using tools like Postman, Newman, and Jenkins.

Postman is a popular API client that allows you to test, share, create, collaborate and document your API development process within a team. An important feature of Postman is the ability to write and run JavaScript-based tests for APIs. Postman offers built-in API integration tools for some continuous integration (CI) tools, such as Jenkins.

Create suites and write automated tests in Postman

First, you need to create a group and fill it with requests. Once the suite is ready, you can start writing automated tests. There are two ways to add JavaScript code:

1. You can add a script that runs before a request is sent to the server, which is done on the Pre-Request Script tab.
2. Alternatively, you can add a script that runs after receiving a response from the server, which is done in the Tests tab.

I usually use the Tests tab. After adding the code to the tab, it will run when the order is executed. The launch result will be available in the test results tab of the response from the server. Dynamic variables can be used in test scripts. You can add data checks from the response and transfer received values ​​between requests.

It is very convenient that Postman offers ready-made code snippets for standard tasks that can be modified to suit your needs to save time. Therefore, this type of automation can be mastered by someone who only knows the basics of JavaScript.

The first simple automated test is to verify that the request was successful, and we have received a status code of 200 (or whatever else we expect). It is more convenient to enable this check at the batch level so that all queries within it inherit this check:

pm.test("Status code is 200", function () {
   pm.response.to.have.status(200);

The following test example is a JSON schema inspection. Why is JSON schema validation needed? because:

• We monitor API responses and ensure that the format we receive is the same as expected.

• We receive an alert when there is any significant change in the JSON response.

• For integration tests, it is useful to check the schema. It can be generated once from a service response in order to test all future versions of the service with it.

  let schema = {
     "items": {
         "type": "boolean"
     }
  };
  
  pm.test("Схема корректна", () => {
     pm.response.to.have.jsonSchema(schema);
  });
  
  

  Thus, we actually have two automated checks for the REST API. I will not bore you with more examples of automatic testing, as they can be found and studied in the documentation at Postman learning websiteSo let’s get to the exciting part: merging our group with Jenkins.

Integrating Postman with Continuous Integration (CI) building systems.

The first question that arises is how to connect Postman and Jenkins. To achieve this, you need to use the CLI (Command Line Interface). Newman, an application that allows you to run and test Postman collections directly from the command line, is used to convert a Postman assembly to the command line language.

Here is a simplified list of steps on how to proceed:

1. Install Jenkins locally And turn it on. For more details, see the Jenkins documentation on Jenkins.io.
2. Install Node.js and Newman in Jenkins:

• Go to your Jenkins server and log in.
• Go to “Manage Jenkins” > “Manage Plugins” and install the NodeJS plugin.
• Go to “Jenkins Administration” > “General Tool Configuration” and select “Add NodeJS” in the NodeJS section.
• Enter a name for your Node.js installation.
• In the ‘Global npm packages’ field, enter newman.
• Select “Save”. Detailed instructions can be found here.

3. Check that npm (the package manager for JavaScript) is installed as well By entering the following commands on the command line:

node -v
npm -v

4. Open the console and install Newman Same using the command:

npm install -g newman

5. Save your collection of tests; You can either create a URL for the tests (Share) or save it as a file (Export).
6. Run the tests in the console using the following command:

   • If using the link:

     newman run   # (replace with the actual URL)
     
     

   • If using a file, use the command with the group file directory:

     newman run /Users/Postman/postman_collection.json
     
     

After running, the tests will be executed in the console, and the results will be displayed:

After running, the tests will be executed in the console, and the results will be displayed.

Then, you can execute Newman from Jenkins after each commit to test the validity of the responses. It is recommended to set up templates in Postman, such as putting the host address and other variable request parameters into variables, which can then be transferred from the Credentials plugin to Jenkins.

8. To configure tasks, add a shell command that includes a Newman call. Next, Jenkins will run the tests. You can set the desired frequency by going to the Design window → Configuration → Build Triggers → Build periodically. Jenkins will then report whether the build was successful or unsuccessful.

You can also set up email distribution to inform team members of the latest releases and statuses. This allows active monitoring of your API structure along with other API components. In addition, there are many other configurations you can implement to make the group more dynamic.

conclusion

In conclusion, I would like to summarize the pros and cons of using this type of automation.

Advantages:

• Postman is intuitive and easy to use.
• It does not require any complicated configuration.
• It supports different APIs (REST, SOAP, GraphQL).
• It easily integrates with CI/CD processes using Newman.
• Newman is easy to use and ideal for those who use Postman frequently and are looking for expanded functionality with minimal effort.

These tools are very effective in adding automation to testing, especially in the initial stages.

Disadvantages:

• Creating automated tests for large projects containing many REST services can be difficult.
• The inability to reuse code may lead to excessive duplication, making maintenance difficult, especially when the number of scripts exceeds 1,000.
• This approach may not be applicable if many tasks are performed within the CI system – such as continuous releases, running automated tests, managing internal dependencies, or deploying releases in an environment. In such cases, you’ll need to increase the number of machines running the automated tests and configure each machine from scratch, ensuring nothing is missed.