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.
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?
## 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.
In the *Test* editor tab, copy and paste the [following test example](https://learning.postman.com/docs/writing-scripts/script-references/test-examples/):
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.
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!
## 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.
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.
Let me hear all about your API testing challenges and success stories on [Discord](https://discord.com/invite/6zupCZFQbe)! That’s where the entire Testkube team and a growing community of fellow Kubernetes testers hang out and share what’s working for them and what they'd love to see in the next Testkube release.