Test Your Cloud-Native Applications with Ginkgo and Testkube

Testing cloud-native applications is essential to ensuring performance, security, and reliability,  but it can be quite challenging to do it right. If you're working with Go, you must be aware of its built-in testing functionalities, which are robust but have many limitations.

‍A great solution to these challenges is integrating Ginkgo with Testkube.

What is Ginkgo Testing?

Ginkgo is a popular, mature, and general-purpose testing framework for the Go programming language that, when paired with Gomega, provides a powerful way to write our tests. With Ginkgo, we can run a huge variety of test types in all sorts of contexts: unit tests, integration tests, performance tests, and so on offering a simple yet powerful solution to most of our testing needs… But how can we efficiently run these tests against cloud native applications? With Testkube, this is no longer a challenge.

Testkube is a cloud-native test execution framework for DevOps, testers, and developers. It acts as an executor, so you can orchestrate, run, and display tests and test results for your code in your environment. With out-of-the-box support for all popular testing tools, Testkube simplifies the transition of your application infrastructure into a Kubernetes environment so you can truly focus on testing.

In this blog, we will walk through how this integration works and explore a couple of examples to get your Go lang testing Go-ing with Ginkgo.

Challenges of Using Ginkgo for Testing Go Apps

While there are multiple benefits of using Ginkgo for testing Go apps, it also comes with some challenges, which makes the testing a bit complicated.

• Issues with Complex Test Suites: It can be challenging to organize complex tests, particularly if the test structure is not kept up to date. This can confuse large codebases.
• Parallelization Issues: Ginkgo allows for parallel execution, but it can make managing shared resources between tests more complicated.
• Learning Curve: Ginkgo introduces a Domain Specific Language (DSL) for writing tests. This language may prove difficult to learn for developers who are familiar with Go's native testing package.
• Dependency Overhead: Because Ginkgo relies on Gomega for assertions, you may need to manage additional dependencies.

Now that we've learned about these challenges associated with the testing of Go apps with Ginkgo, let's look at how we can incorporate Teskube with Ginkgo into our Kubernetes environments for more seamless testing. To do so, let us first write a Go test.

Writing Ginkgo Golang Tests

As we mentioned before, Ginkgo allows us to write multiple types of tests. Built on top of Go's testing infrastructure, it lets developers and testers write more expressive tests by using the blocks Describe, Context, It, BeforeEach, and AfterEach. These let us define what we're testing, when, and before or after certain unit tests.

For this blog, we'll start with a simple one to test an HTTP request and response. To achieve this, we have created a Go test suite as shown below:

package e2e

import (
	"flag"
	"testing"

	. "github.com/onsi/ginkgo/v2"
	. "github.com/onsi/gomega"
)

var baseURL string

// Register your flags in an init function.  This ensures they are registered _before_ `go test` calls flag.Parse().
func init() {
	flag.StringVar(&baseURL, "base-url", "", "Url of the server to test")
}
func TestE2e(t *testing.T) {
	RegisterFailHandler(Fail)
	if baseURL == "" {
		baseURL = "google.com"
	}
	RunSpecs(t, "E2E Integration Testing Suite")
}

Here is the url_test.go that will check the URL for status code 200. In this example, we have sent a request to https://google.com.

package e2e

import (
	"fmt"
	"net/http"

	. "github.com/onsi/ginkgo/v2"
	. "github.com/onsi/gomega"
)

var _ = Describe("Try Google for a 200", func() {
	It("should return 200", func() {
		resp, requestErr := http.Get(fmt.Sprintf("https://%s", baseURL))
		Expect(requestErr).To(BeNil())
		Expect(resp.StatusCode).To(Equal(200))
	})
})

You can find the project here. Let us run this Ginkgo test suite using Testkube.

Using Testkube to Run Ginkgo Tests in Kubernetes

Running Ginkgo tests as part of your build-process makes sense if your tests are low-level unit or component tests, but higher-level tests (performance, E2E, etc) will usually need to be run against a testing or staging environment that provides the full functionality of the application or service under test. This is where Testkube comes in; Testkube leverages the scalability and flexibility of Kubernetes to run any testing tool or script from inside your application environment, removing any requirement to “open up” your cluster or infrastructure for tests running from external CI/CD tools and pipelines. Furthermore, Testkube aggregates all logs and results for your test executions over time, providing you with a single Dashboard for troubleshooting and analyzing test results for any tests you may be running, including of course the Ginkgo tests in this example.

To get started, you'll need to have Testkube running on your cluster. If you haven't already, sign up for free and get started right away—or read our installation Guide. Once you've set up Testkube, we can start creating a JMeter Test Workflow.

Prerequisites

• Get a Testkube account.
• Kubernetes cluster - we’re using a local Minikube cluster.
• Testkube Agent configured on the cluster.

Once the prerequisites are met, you can launch a target Kubernetes cluster with a configured Testkube agent.

Creating a Ginkgo Test Workflow

Testkube requires you to define Test Workflows to run your tests. Test Workflows can then be triggered in your environment throughout the development process. Let's create a Ginkgo Test Workflow that we will use to configure and run Ginkgo test:

kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: ginkgo-test
  namespace: testkube
  labels:
    docs: example
spec:
  content:
    git:
      uri: https://github.com/kubeshop/testkube/
      revision: main
  container:
    workingDir: /data/repo/contrib/executor/ginkgo/examples/e2e
  steps:
  - name: Run test
    container:
      image: cerebro31/ginkgo-test:latest
    shell: |
      ginkgo run -r --json-report=report.json --output-dir=/data/report
    artifacts:
      paths:
      - /data/report/*
status: {}

The spec file includes the following components:

• The `spec` section defines the core configuration of the Test Workflow. It includes the following key components: some text
  • Content, which specifies the source of the test's content. In this case, the content is pulled from a Git repository.
  • The git component includes uri, which specifies the URL of the Git repository containing the test code. This refers to the kubeshop/testkube repository. In addition to the uri, it includes the revision and container. The revision specifies which branch or tag will be used from the repository. In this case, it's set to "main." The container section describes the container settings that will be applied during workflow execution.
• The `content` section specifies the source of the test's content. 
• The `steps` section describes the sequential actions that the workflow will take. Each step is responsible for carrying out a specific task within the workflow.some text
  • `container.image`: We have created a custom Ginkgo image and uploaded it on DockerHub.
  • `shell`: Runs Gingko and saves the generated report in a file.
  • `artifacts.paths`: Uploads the generated report so that you can access it.

Read the Test Workflow documentation to learn more about the Test Workflow specification.

Setting up the Test Workflow in Testkube

Testkube offers a variety of ways to create test workflows that can be tailored to meet the needs of various users. Here, we'll use Import from YAML to create a test workflow from the workflow above..

Navigate to the test workflow section and click the “Add New Test Workflow” button. 

A “Create a Test Workflow” dialog box appears that provides you with four options to create a Test Workflow:

• Create from Wizard: This option displays a dialog box prompting you to create a new Test Workflow.
• Start from an Example: This configuration enables the use of pre-configured examples, including Cypress, Playwright, Postman, Playwright, k6, and many others.
• Combine Existing Workflows: By selecting this option, you can sequentially or simultaneously execute and combine multiple existing Test Workflows.
• Import from YAML: Using this option, you can import a Test Workflow from a YAML definition.

Choose the “Import from YAML” option to create this workflow.

When you click the "Import from YAML" option, a Test Workflow dialog box appears. This dialog allows you to create a new test workflow with a YAML file that can be customized for specific test steps. 

In the YAML configuration field, paste your customized YAML file and then select the "Create & Run" option to generate and execute the Test Workflow.

Executing the Test Workflow

After clicking the "Create & Run" button, the Test Workflow will start.

To view the log output, select each test procedure step.

The successful test message can be seen in the log output. Testkube collects all artifacts after execution, including a stats report with all of the outputs and results.

‍

Select "Artifacts” and you can see the directory created by Testkube. Select the report directory. 

Testkube has uploaded the report.json file. Download the file to view the complete execution details. Here is how report.json looks for our test execution:

[
  {
    "SuitePath": "/data/repo/contrib/executor/ginkgo/examples/e2e",
    "SuiteDescription": "E2E Integration Testing Suite",
    "SuiteLabels": [],
    "SuiteSucceeded": true,
    ...
    "StartTime": "2024-09-24T13:10:49.614069379Z",
    "EndTime": "2024-09-24T13:10:50.599520457Z",
    "RunTime": 985451108,
    ...
    "SpecReports": [
      {
        "ContainerHierarchyTexts": [
          "Try Google for a 200"
        ],
        ...
        "LeafNodeLocation": {
          "FileName": "/data/repo/contrib/executor/ginkgo/examples/e2e/url_test.go",
          "LineNumber": 12
        },
        "LeafNodeLabels": [],
        "LeafNodeText": "should return 200",
        "State": "passed",
        "StartTime": "2024-09-24T13:10:49.614124103Z",
        "EndTime": "2024-09-24T13:10:50.599474862Z",
        "RunTime": 985350798,
        "ParallelProcess": 1,
        "NumAttempts": 1,
        "MaxFlakeAttempts": 0,
        "MaxMustPassRepeatedly": 0,
        "SpecEvents": [
        ...
            "Message": "should return 200",
            "Duration": 985321645,
            "NodeType": "It"
          }
        ]
      }
    ]
  }
]

The above report shows the successful execution of the Ginkgo test. This was a simple demonstration of the process of importing a YAML file into Testkube to create a Test Workflow. You can effortlessly create and import custom workflows that are specifically designed to meet your testing requirements by using this approach. 

Summary

As you can see, using Testkube with Ginkgo can provide us with a lot more flexibility when writing and executing expressive tests in Go. Whether you use Ginkgo to write expressive tests in Go or another testing framework, Testkube makes it easier to manage and execute tests for your cloud-native applications. Explore more such example projects and read our extensive documentation to learn how Testkube can improve your testing strategy.

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!