Simplifying API Test Automation with Postman and Testkube

Juan Ibarra - Sep 30 - - Dev Community

As an industry, we are moving away from monolithic architectures for many applications and adopting API-first mode. APIs have become the building blocks of applications, making our applications modular and scalable. This approach focuses on building robust APIs from the start.

Kubernetes simplifies deploying and managing such API-based applications at scale. However, API reliability and performance require comprehensive testing as the applications grow and become more distributed. Issues like ephemeral resources, load balancing complexities, service discovery mechanisms, and the distributed nature of Kubernetes clusters make it challenging to execute API tests reliably.

Tools like Postman help you with testing your APIs. However, using Postman with Testkube allows developers to streamline API testing workflows within Kubernetes clusters. In this post, we’ll look at creating a Test Workflow using Postman in Testkube.

API Testing Using Postman

Postman is one of the most widely adopted API testing tools. It provides a suite of features for designing, testing, and monitoring APIs. Its intuitive dashboard, rich feature set, and user experience make it a go-to choice for developers and testers alike. Some of Postman’s features include:

  • User-friendly UI: Postman's UI is intuitive, seamless, and user-friendly, allowing you to build and test APIs easily.

  • Automated testing: Postman allows you to write automated tests using its built-in capabilities to create and build comprehensive test suites.

  • Environment management: Postman simplifies environment management by allowing you to create and seamlessly switch between environments.

You can read more about Postman here.

Creating API Tests In Postman

One of the main reasons Postman is a popular choice for API testing is the ease with which it allows developers to create and manage APIs. Once you have the API endpoints you want to test, creating a request and an associated test is straightforward.

In this case, we’ll use the https://restful-api.dev/ endpoint, a free-to-use API for testing. To use it, you create a collection and add a request to it. By tweaking the endpoints, we added three requests: GetAllObjects, GetObjectsById, and GetSingleObject.

Image description

We can also add tests to each request based on your requirements. The tests are written in JavaScript and are used to validate the responses from the endpoint.

Image description

You can then export the collection as a JSON file, which we’ll use to create the Test Workflow. To do that, Click on the three dots next to the Collection Name and click Export.

Challenges With Postman in Kubernetes

While Postman works great for API testing in traditional environments, managing them in Kubernetes using Postman is challenging and complex. Some of these challenges are:

  • Service discovery: The Kubernetes service discovery mechanism allows services to change their IP addresses and ports frequently, complicating the configuration of Postman tests.

  • Test Orchestration: Orchestrating and managing Postman tests across nodes and pods can be challenging, especially when dealing with dependencies and parallel tests.

  • Test data management: Without proper tooling, managing and sharing test data across different clusters and nodes can become complex.

To overcome these issues, you can turn to specialized tools like Testkube, which is explicitly designed for running tests in Kubernetes.

Using Postman With Testkube

Testkube is a Kubernetes-native testing framework designed to streamline the orchestration of tests on Kubernetes. It adopts a declarative and version-controlled approach that enables developers to manage tests as Kubernetes resources. Below are some benefits of using Testkube:

  • Integration With Testing Tools: Testkube integrates with many testing tools like Cucumber, k6, Cypress, etc., enabling you to leverage the power of Kubernetes for your tests.

  • Simplified Workflow Creation: Without complex scripting, Testkube facilitates the creation of detailed test workflows, allowing for better control and customization of test executions. Refer to our Test Workflows documentation to learn more.

  • Kubernetes Native: By storing tests as Kubernetes Custom Resource Definitions (CRDs), Testkube ensures compatibility and scalability.

  • Integration with CI/CD Tools: Testkube seamlessly integrates with existing CI/CD pipelines, enhancing end-to-end testing capabilities.

Let’s see how to create a Test Workflow for Postman using Testkube. All the files used for this demo can be found in the Testkube Examples GitHub repo.

Pre-requisites

Once the prerequisites are in place, you should have a target Kubernetes cluster ready with a Testkube agent configured.

Creating a Test Workflow

Navigate to the Test Workflows tab and click on "Add a new test workflow".

This will provide you with three options:

  • Create from scratch: Use the wizard to create a Test Workflow.

  • Start from an example: Use existing k6, cypress, and playwright examples.

  • Import from YAML: Import your own Test Workflow.

We’ll choose the "create from scratch" option to create this workflow.

  • Provide a name for the workflow and choose the type as Postman.

  • Provide a Postman version, we’ll use 6-alpine.

  • Provide the run command. In this case, we’ll provide newman run .json.

Image description

On the next screen, provide the source for the test file. This can either be a Git Repo, String, or a file. In this case, we’ll use a Git repo. Further, we’ll provide the path as “postman-workflow”.

Image description

On the next screen, it will generate the YAML spec file and display the output.

Image description

kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: postman-testkube
  namespace: testkube
  labels:
    test-workflow-templates: "yes"
spec:
  use:
  - name: official--postman--beta
    config:
      run: newman run RestAPITestParams.postman_collection.json
      version: 6-alpine
  content:
    git:
      uri: https://github.com/kubeshop/testkube-examples.git
      revision: main
      paths:
      - postman-workflow
  container:
    workingDir: /data/repo/postman-workflow
Enter fullscreen mode Exit fullscreen mode

The yaml file is self-explanatory as it lists down the details you’ve provided in the yaml.

…
"item": [
        {
            "name": "GetAllObjects",
            "event": [
                {
                    "listen": "test",
                    "script": {
                        "exec": [
                            "// Check the HTTP status code",
                            "pm.test(\"Status code is 200\", function () {",
                            "   pm.response.to.have.status(200);",
                            "});",
                            "",
                            "// Check the number of items returned",
                            "pm.test(\"Item count is 13\", function () {",
                            "   var jsonData = pm.response.json();",
                            "   pm.expect(jsonData.length).to.eql(13);",
                            "});"
                        ],
                        "type": "text/javascript"
                    }
                }
            ],
…
Enter fullscreen mode Exit fullscreen mode

Above is a snippet from the json collection which has three APIs and a few tests associated with each. All APIs make a GET request to an endpoint, some with parameters and some without. The tests here validate the API response.

Click on “Create” to create the test workflow.

Setting Up Variables

The last step before executing the Test Workflow is to set up variables. The Postman_collection currently requires the following two variables to execute:

  • url: This is the base URL of the API endpoint.

  • id: This is the object_id parameter that will be passed in the API call.

Select the newly created Test Workflow to configure these variables and navigate to Settings -> Variables & Secrets. Here, add these two variables and click Save. This will configure the Test Wofklow to use the variables, which will also reflect in the yaml spec

Image description

After this, you need to configure the Test Workflow’s yaml spec to pass these variables with the execution command. Navigate to Definition tab and edit the run command as shown below:

<span>newman run RestAPITestParams.postman_collection.json --env-var "id=${id}" --env-var
</span>"url=${url}"
Enter fullscreen mode Exit fullscreen mode

With this, you have configured the Test Workflow to use the value of “2” for id and “api.restful-api.dev” for url, respectively. You can tweak these variables based on your requirements.

Executing the Test Workflow

Once the workflow is ready, you’ll see the newly created test workflow on the screen. Click on it and click “Run Now” to start the workflow.

You’ll see the workflow executing along with the real-time logs of every step.

Image description

You’ll see the test result based on the test execution. In this case, you’ll see that all the tests have passed. If you want to fail the Test Workflow, you must change the “id” variable to some other number between 1-12 and see how the output changes.

This was a simple demo of creating a Postman Test Workflow using Testkube for API testing in Kubernetes. To take advantage of test workflows more, you can create custom workflows and import them to Testkube.

Summary

In this post we looked at how API first design approaches are getting popular. Many Java applications are also adopting this design principle, and tools like RestAssured are gaining popularity in testing APIs. We also looked at RestAssured and the complexities of running it on Kubernetes.
We then saw how using RestAssured with Testkube, you can create an end-to-end workflow for API testing leveraging the power of Kubernetes.

Visit the Testkube website to learn more about the other testing tools you can integrate with. If you struggle with anything, feel free to post a note in our active Slack community.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .