Responsive

API Testing in Kubernetes with Postman and Testkube

Sep 12, 2022
9 min
read
Learn more about how to test APIs in Kubernetes with Postman and Testkube.
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL

Table of Contents

Want to learn more about this topic? Check out our Office Hours sessions!

Get Started with Testkube Pro

If you are a QA engineer or a software developer, regardless of your stack—you’ll want to be the kind who helps ship bug-free code at a healthy pace so you need to be able to test the APIs that you’re creating.

That’s true for all your environments, be it, staging, testing, or production. You’re always creating new APIs and developing against public or third-party APIs.

But there are a few challenges when it comes to API testing:

- The access to the environments you are testing against could be restricted. Could be that your APIs are behind a VPN or a firewall or you need a special kind of authentication.

- Schemas and protocols that might not be fully documented.

- Differences in the various environments (testing vs. staging vs. production) where your API tests could pass in some but not all environments.

- Changes in APIs due to ongoing API development and the necessity to test multiple versions.

As a developer or tester, what you’re really looking for with API testing is confidence. Are your API’s doing what they are supposed to?

## The state of API testing in Kubernetes

Building a test suite capable of adequately testing your API is hard enough without all the barriers that modern infrastructure puts in your way. Kubernetes' appeal is that it has a robust [network model](https://kubernetes.io/docs/concepts/services-networking/) that abstracts most of the complexity around networking, but still there’s some. Most developers/testers create test runners to get around the network access issues that come with running a Kubernetes inside a protected network. These are often Docker containers, including all the dependencies required to run the API test, that you send to the Kubernetes cluster for processing.

Let’s say you’re using [Postman](https://www.postman.com/), one of the most popular tools for designing, documenting and testing your APIs in Kubernetes. You would create one or more Docker-based runners that can take your Postman collections, which are groups of one or more Postman API tests, and “inject” them into your Kubernetes cluster, and run them against your microservices in the way you’ve specified.

But creating and maintaining these runners isn’t necessarily a trivial task,and this is where Testkube comes in!

## How Testkube does Kubernetes API testing differently

Think of Testkube as a “bridge” between your Postman tests and the internal workings of your Kubernetes cluster.

It’s the most complete and developer-friendly test executor you could ever hope for as a developer or tester. [Install Testkube once](http://testkube.io/get-started), without the headache of Docker configurations, and execute your API tests from inside your cluster. 

Testkube works great with [Postman](https://learning.postman.com/docs/getting-started/introduction/) collections, but it also supports 11+ additional tools, platforms, and plugins to help you centralize your test orchestration and reporting on a single UI. Seamlessly hop between API, UI, load tests, and more, using tools like [Cypress](http://testkube.io/integrations/cypress) or [k6](http://testkube.io/integrations/k6/), for truly holistic Kubernetes testing.

Running tests from inside your cluster is the best way to ensure reliable tests that allow you to bypass issues involving connectivity to your cluster. Which you can easily trigger in your CI/CD or using Testkube’s more user-friendly UI to have a better look at the state of your tests.

Kubernetes Testing Dashboard Screenshot

With Testkube and Postman together you will be sure to achieve the most robust and uncomplicated API testing in Kubernetes, you can quickly and repeatedly validate how your application responds in many ways:

- Performance: What’s the latency between receiving a standard query and returning a valid response?

- Security: What’s contained in the response’s JSON/XML output, and does that leak and private user data?

- Correctness: Does the response contain all the data you need and nothing extra?

- Uptime:  Does your API request  respond every time?

And, perhaps most importantly, does your application do what you expect when you push one of its API buttons?

Running Postman test in Kubernetes

## Creating your first Postman API test in Testkube

As a tester, you can install Testkube on your command line to create, manage, and run your API tests or/and just access the Testkube UI, which runs from within your cluster and do it from there.

To keep this article simple, we’ll create and run a test against [Testkube’s demo cluster and UI](https://demo.testkube.io/tests), which you can freely use to experiment with all of Testkube’s features and test types, which also include [k6](https://kubeshop.io/blog/load-testing-in-kubernetes-with-k6-and-testkube), [SoapUI](https://testkube.io/blog/run-kubernetes-tests-with-soapui-and-testkube), [Cypress](https://testkube.io/blog/end-to-end-tests-of-your-kubernetes-applications-with-cypress), and more…

When you’re ready to run Testkube on your own cluster, you can install both the CLI tooling and Testkube components in [two simple commands](https://kubeshop.github.io/testkube/installing/).

## Create your Postman API test

In the Postman UI, create a new collection, and within that, create a new health API test. Choose a GET request and select `http://testkube-api-server:8088/health` as the request URL.

Postman frontend

In the *Test* editor tab, copy and paste the [following test example](https://learning.postman.com/docs/writing-scripts/script-references/test-examples/):

Test setup

This test will send a GET request to the `/health` endpoint on the service `testkube-api-server`, which runs on port *8088*. If the cluster responds as expected—a status *200* response—then the test passes.

Right-click on your collection to export it to a JSON file, which allows you to run multiple API tests against your Kubernetes cluster in the same execution.

Open [Testkube’s demo UI](https://demo.testkube.io/tests), click *Add a new test*. Name your test, select *postman/collection* from the *Type* dropdown list, then choose *File* from the *Source* dropdown and find the JSON file you just downloaded from Postman. Click *Create* to initiate your test.

Creating a test cloud natively

Click the *Settings* tab, then *Variables & Secrets*, to define environment variables or add database secrets.

Once you have everything set up, click *Run now* to run your API tests against your Kubernetes cluster!

Trigger event setup

## View logs and results in the Testkube UI

Click on *Recent executions* to view your test. At a glance, a green checkbox next to your most recent execution (there will likely only be one at the moment) indicates a *PASS*, whereas a red X lets you know that your test returned a *FAIL*.

Click on the execution to see the log output and various contextual information, like the variables you passed and the timeframe your test ran.

Postman running within web gui

At this point, you can continue tweaking your Postman collection, adding more or more complex API tests, or you can start automating your API testing by running tests using the Testkube CLI and your [existing CI/CD pipeline on GitHub Actions](https://docs.testkube.io/articles/cicd-overview/).

## What’s next?

Now that you’ve run a Postman API test against Testkube’s demo cluster and gotten familiar with how to use the Testkube UI, you’re ready to install it [in your cluster](http://testkube.io/get-started). which will unlock for you a high level of test automation, all of Testkube’s supported test types, and a results database for a centralized test result management.

With a single UI for all your Kubernetes testing needs, you’ll be able to build and deploy more comprehensive API tests in a fraction of the time. Discover regressions, speed up the velocity in your deployments, and have confidence that your APIs work as expected.

Why not give it a go yourself? Sign up to Testkube and try one of our examples or head over to our documentation - if you get stuck or have questions, we’re here to help! Find an answer to your questions in the Testkube Knowledge Base or reach out to us on Slack. We’re eager to hear how you use our integrations!

Responsive
Testkube blog

API Testing in Kubernetes with Postman and Testkube

9 min
read
Bruno Lopes
Product Leader
Testkube
Learn more about how to test APIs in Kubernetes with Postman and Testkube.
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL

Table of Contents

Get Started with Testkube Pro

If you are a QA engineer or a software developer, regardless of your stack—you’ll want to be the kind who helps ship bug-free code at a healthy pace so you need to be able to test the APIs that you’re creating.

That’s true for all your environments, be it, staging, testing, or production. You’re always creating new APIs and developing against public or third-party APIs.

But there are a few challenges when it comes to API testing:

- The access to the environments you are testing against could be restricted. Could be that your APIs are behind a VPN or a firewall or you need a special kind of authentication.

- Schemas and protocols that might not be fully documented.

- Differences in the various environments (testing vs. staging vs. production) where your API tests could pass in some but not all environments.

- Changes in APIs due to ongoing API development and the necessity to test multiple versions.

As a developer or tester, what you’re really looking for with API testing is confidence. Are your API’s doing what they are supposed to?

## The state of API testing in Kubernetes

Building a test suite capable of adequately testing your API is hard enough without all the barriers that modern infrastructure puts in your way. Kubernetes' appeal is that it has a robust [network model](https://kubernetes.io/docs/concepts/services-networking/) that abstracts most of the complexity around networking, but still there’s some. Most developers/testers create test runners to get around the network access issues that come with running a Kubernetes inside a protected network. These are often Docker containers, including all the dependencies required to run the API test, that you send to the Kubernetes cluster for processing.

Let’s say you’re using [Postman](https://www.postman.com/), one of the most popular tools for designing, documenting and testing your APIs in Kubernetes. You would create one or more Docker-based runners that can take your Postman collections, which are groups of one or more Postman API tests, and “inject” them into your Kubernetes cluster, and run them against your microservices in the way you’ve specified.

But creating and maintaining these runners isn’t necessarily a trivial task,and this is where Testkube comes in!

## How Testkube does Kubernetes API testing differently

Think of Testkube as a “bridge” between your Postman tests and the internal workings of your Kubernetes cluster.

It’s the most complete and developer-friendly test executor you could ever hope for as a developer or tester. [Install Testkube once](http://testkube.io/get-started), without the headache of Docker configurations, and execute your API tests from inside your cluster. 

Testkube works great with [Postman](https://learning.postman.com/docs/getting-started/introduction/) collections, but it also supports 11+ additional tools, platforms, and plugins to help you centralize your test orchestration and reporting on a single UI. Seamlessly hop between API, UI, load tests, and more, using tools like [Cypress](http://testkube.io/integrations/cypress) or [k6](http://testkube.io/integrations/k6/), for truly holistic Kubernetes testing.

Running tests from inside your cluster is the best way to ensure reliable tests that allow you to bypass issues involving connectivity to your cluster. Which you can easily trigger in your CI/CD or using Testkube’s more user-friendly UI to have a better look at the state of your tests.

Kubernetes Testing Dashboard Screenshot

With Testkube and Postman together you will be sure to achieve the most robust and uncomplicated API testing in Kubernetes, you can quickly and repeatedly validate how your application responds in many ways:

- Performance: What’s the latency between receiving a standard query and returning a valid response?

- Security: What’s contained in the response’s JSON/XML output, and does that leak and private user data?

- Correctness: Does the response contain all the data you need and nothing extra?

- Uptime:  Does your API request  respond every time?

And, perhaps most importantly, does your application do what you expect when you push one of its API buttons?

Running Postman test in Kubernetes

## Creating your first Postman API test in Testkube

As a tester, you can install Testkube on your command line to create, manage, and run your API tests or/and just access the Testkube UI, which runs from within your cluster and do it from there.

To keep this article simple, we’ll create and run a test against [Testkube’s demo cluster and UI](https://demo.testkube.io/tests), which you can freely use to experiment with all of Testkube’s features and test types, which also include [k6](https://kubeshop.io/blog/load-testing-in-kubernetes-with-k6-and-testkube), [SoapUI](https://testkube.io/blog/run-kubernetes-tests-with-soapui-and-testkube), [Cypress](https://testkube.io/blog/end-to-end-tests-of-your-kubernetes-applications-with-cypress), and more…

When you’re ready to run Testkube on your own cluster, you can install both the CLI tooling and Testkube components in [two simple commands](https://kubeshop.github.io/testkube/installing/).

## Create your Postman API test

In the Postman UI, create a new collection, and within that, create a new health API test. Choose a GET request and select `http://testkube-api-server:8088/health` as the request URL.

Postman frontend

In the *Test* editor tab, copy and paste the [following test example](https://learning.postman.com/docs/writing-scripts/script-references/test-examples/):

Test setup

This test will send a GET request to the `/health` endpoint on the service `testkube-api-server`, which runs on port *8088*. If the cluster responds as expected—a status *200* response—then the test passes.

Right-click on your collection to export it to a JSON file, which allows you to run multiple API tests against your Kubernetes cluster in the same execution.

Open [Testkube’s demo UI](https://demo.testkube.io/tests), click *Add a new test*. Name your test, select *postman/collection* from the *Type* dropdown list, then choose *File* from the *Source* dropdown and find the JSON file you just downloaded from Postman. Click *Create* to initiate your test.

Creating a test cloud natively

Click the *Settings* tab, then *Variables & Secrets*, to define environment variables or add database secrets.

Once you have everything set up, click *Run now* to run your API tests against your Kubernetes cluster!

Trigger event setup

## View logs and results in the Testkube UI

Click on *Recent executions* to view your test. At a glance, a green checkbox next to your most recent execution (there will likely only be one at the moment) indicates a *PASS*, whereas a red X lets you know that your test returned a *FAIL*.

Click on the execution to see the log output and various contextual information, like the variables you passed and the timeframe your test ran.

Postman running within web gui

At this point, you can continue tweaking your Postman collection, adding more or more complex API tests, or you can start automating your API testing by running tests using the Testkube CLI and your [existing CI/CD pipeline on GitHub Actions](https://docs.testkube.io/articles/cicd-overview/).

## What’s next?

Now that you’ve run a Postman API test against Testkube’s demo cluster and gotten familiar with how to use the Testkube UI, you’re ready to install it [in your cluster](http://testkube.io/get-started). which will unlock for you a high level of test automation, all of Testkube’s supported test types, and a results database for a centralized test result management.

With a single UI for all your Kubernetes testing needs, you’ll be able to build and deploy more comprehensive API tests in a fraction of the time. Discover regressions, speed up the velocity in your deployments, and have confidence that your APIs work as expected.

Why not give it a go yourself? Sign up to Testkube and try one of our examples or head over to our documentation - if you get stuck or have questions, we’re here to help! Find an answer to your questions in the Testkube Knowledge Base or reach out to us on Slack. We’re eager to hear how you use our integrations!

Bruno Lopes
Product Leader
Testkube
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL