Enterprises have long relied on monolithic applications to run their operations and provide different functions and services to their customers.
Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent. If any program component requires an update, the whole application must be redeployed. As enterprises continue to grow their customer base, they will need to upgrade and scale their monolithic architecture.
Trying to uncontain the monolith
The more services and functions developers create onto the monolith, the more difficult it becomes to untangle the code for future upgrades.
The challenges associated with upgrading and scaling monolithic applications are tedious. It eventually led developers to create the microservices-based application architecture. The experts over at SmartBear define microservices as “the idea of offering a broader platform, application, or service as a collection of combined services. These microservices provide specialized, fine-grained cooperation that makes up the more comprehensive architecture model.”
Microservices, in essence, offers a broader platform, application, or service as a collection of combined services. These microservices provide specialized, fine-grained cooperation that makes up the more comprehensive architecture model. The use of microservices in apps can be structured in many ways.
Within the application, a microservice does one defined job – for example, authenticating users, generating a particular data model, or creating a particular report.
What is Kubernetes?
Microservices can get tricky when you’re in a distributed cloud-based environment with lots of moving parts. Enter Kubernetes. Kubernetes is a popular component management system that provides a configurable layer for deploying, managing, and scaling the parts of a microservices application. Kubernetes or K8s, is portable, extensible, and open-source platform for managing containerized workflows and services. It groups the containers that make up an application, using the concept of “pods” and “labels,” into logical units for ease of management and discovery.
In this blog, we’ll discuss how to move and run your SoapUI tests in your Kubernetes cluster using Testkube.
What is Testkube?
Testkube is a Kubernetes-native testing framework. It enables running tests directly in your Kubernetes cluster and then saves the results to a centralized space. It abstracts away all the troubles of containerizing different test types. Testkube makes testing in Kubernetes a smooth cloud-native experience.
SoapUI + Testkube: the perfect fit
In a 2021 study published by RedHat, 88% of RedHat customers use Kubernetes with 74% in production. Kubernetes is at the base of most modern cloud-native applications. The number of users will keep growing with all the major cloud providers coming out with their own managed version.
Running SoapUI tests in a Kubernetes cluster should be as simple as one command - that’s what Testkube enables. Writing complex scripts for automation is a possible solution but can be time consuming and error prone. It involves updates every time a user discovers an edge case. It is worth doing only when there is a reason to have complete control over the flow.
Another issue concerning microservices is that some APIs should not be public on the internet. Testing on the same Kubernetes cluster does not need a sophisticated firewall setup. They still have enough distance from the service to emulate incoming requests.
The good folks over at Testkube, made sure to address both concerns. Testkube executes tests with one command, and can run in any Kubernetes cluster. It is a natural step in migrating SoapUI tests to Kubernetes. Especially now that there's an executor for it!
Below you can see how Testkube tests your API and microservices using SoapUI project file.
Running your first test
Installing Testkube is enough to equip your environment for SoapUI tests.
Running this project using the Testkube CLI is as easy as:
Creating a test
kubectl testkube create test --file "example-project.xml" --type "soapui/xml" --name example-test
Starting and following the output of the test
kubectl testkube run test -f example-test
(Optional) Running specific test cases
kubectl testkube run test -f example-test --args '-I -c "Testkube"'
As the last command shows, Testkube forwards arguments to the SoapUI executor. The full list of accepted parameters is in the official SoapUI documentation. Keep in mind that these tests are running ultimately in a containerized environment. Thus, some of the original parameters will behave differently, for example -I will likely not be able to prompt the usual way.
SoapUI executor CRD
Behind the scenes, Testkube works with Kubernetes' Custom Resource Definitions (CRDs). Tests and test suites have their own CRDs defined, as well as Executors. An executor is basically a Testkube-specific test runner. There are already many executors implemented to run Cypress, K6, etc. tests.
The definition of the SoapUI executor CRD looks the following way:
apiVersion: executor.testkube.io/v1
kind: Executor # defines the type of the resource
metadata:
name: soapui-executor # name of the executor
namespace: testkube # all Testkube resources are in the 'testkube' K8s namespace
spec:
executor_type: job # the only possible type, tests are run in k8s jobs
image: kubeshop/testkube-executor-soapui:latest # Docker image
types:
- soapui/xml # defines the input types, 'soapui/xml' is the only supported one
content_types:
- string # test content is a string
- file-url # test content is in a file
features:
- artifacts # the logs from SoapUI will appear as artifacts for easier access
Downloading Testkube is enough to have access to the SoapUI executor.
SoapUI test in Testkube UI
Testkube also offers a neat browser app to show you an overview of all your tests. Here's what one of my (finally) successful tests looks like in the dev environment:
The UI also gives you quick access to CLI commands to work with tests and test executions. There's a separate tab for the definition of the test. Clicking on an execution shows further details: logs, relevant files (artifacts) and commands.
Limitations
As mentioned before, running SoapUI in a container limits its functionalities. Opening up a browser with the results and working with prompts will be challenging.
As of now, using volumes with Testkube tests is not implemented. Therefore, anything related to volumes is not supported:
- Mounting a project directory
- Getting the generated report directories and files in a volume
- Mounting extensions or plugins
Third-party libraries are not supported. For some, like using JDBC drivers, the Maven executor provides a workaround.
Further steps & getting started with Testkube
Now you can leverage existing SoapUI tests in your Kubernetes infrastructure, and it’s simply from using Testkube.
Download Testkube from GitHub or view the Testkube website for more information on how to get started. Get in touch to complain or praise Testkube on their Discord Server.
For more information about SoapUI + Testkube, check out our recent webinar with the Testkube team.