End To End local integration test

Camel K has a suite of integration test that will run on every Pull Request. You can contribute by adding an integration test to cover any new feature introduced (or increment the coverage with features still untested).

Since both unit test and integration test names end with _test.go, both would be executed by go during the build, so you need to put a special build tag to mark integration tests. An integration test should start with the following line:

//go:build integration
// +build integration

Look into the /e2e directory for examples of integration tests.

Before running an integration test, you need to be connected to a Kubernetes/OpenShift namespace. After you log into your cluster, you can run the following command to execute the suite of smoke tests:

make test-smoke

The test script will install the operators needed in a random namespace, execute all expected tests and clean themselves. Cleaning may not be performed if the execution of tests fails or the test process is interrupted. In that case you can look for any namespace similar to test-29ed8147-c9fc-4c04-9c29-744eaf4750c6 and remove it manually.

End-To-End tests structure

We have several kind of end-to-end tests. Most of them will only require the installation of Camel K operator, but, others need some particular configuration. This is the reason why they may not work out of the box on your cluster. The main goal of the test is to run in a CI environment, so, all requirements are scripted accordingly. If you want to run a test in your cluster, make sure to provide the configuration as expected by the test suite.

This is the list of the groups we are using (please, notice that they can slightly change in the future):

  • builder (make test-builder)

  • common (make test-common)

  • advanced (make test-advanced)

  • install (make test-install, make test-install-olm and make test-install-upgrade)

  • knative (make test-knative)

  • native (make test-quarkus-native and make test-quarkus-native-high-memory)

  • telemetry (make test-telemetry)

Each group tests a specific feature of Camel K. Typically any new test should be falling under the common group, unless it belongs to any other category or it requires some particular customization. As an example, telemetry requires the configuration of an OTLP Collector, reason why it requires its own group. If the test still is a common one but needs to perform customization on the Camel K Operator, then, it should be developed under advanced: as an example, we have there tests which requires the configuration of a Maven proxy.

It’s important to know that a subset of common named test-smoke is used as smoke test in the nightly release process. We want to keep this group of test as fast as possible.

Configure End To End tests runs with env vars

Some e2e test runs parameters can be configured usually with env vars. Most of them are located at e2e/support/test_support.go in init and kamelInstallWithContext functions. A list of the most commonly used:

  • CAMEL_K_TEST_SKIP_PROBLEMATIC: set it to true to skip tests that might fail.

Testing Operator under development

You probably want to test your changes on camel-k operator locally after some development. You will need to make the operator docker image available to your cluster registry before launching the tests. We have a script which will take care of that.

First, you must connect and point to the docker daemon. If you’re on a local environment such as minikube, it will be as simple as executing

eval $(minikube -p minikube docker-env)

For other cluster types you may check the specific documentation. As soon as you’re connected to the docker daemon you can build images via:

make images

The script will build the operator docker image and push it to the underlying docker daemon registry. At this stage, the cluster will be able to pickup this latest image when it executes the tests.

You can also execute the following script, if by any chance you have some change applied to the camel-k-runtime. You can optionally point to your local Camel K runtime project directory if you need to install any local SNAPSHOT dependency:

make images [CAMEL_K_RUNTIME_DIR=/path/to/camel-k-runtime-project]

Using remote cluster

If you don’t have enough machine resources to run the test locally (a local Kubernetes cluster may require up to 32 GB of memory and several CPUs), then, you can push your operator image to some remote registry that is also reachable from your Kubernetes cluster.

make images CUSTOM_IMAGE=docker.io/my-org/my-ck-operator-test

Then, you need to use a couple of environment variables in order to let the test know the container image to use.

export CAMEL_K_TEST_OPERATOR_IMAGE=docker.io/my-org/my-ck-operator-test:2.0.0-SNAPSHOT
export CAMEL_K_TEST_OPERATOR_IMAGE_PULL_POLICY=Always // this may not be required, use only if you want to change the policy

Make sure your local Kubernetes config settings is pointing to the right cluster (ie, kubectl config current-context) and run the suite of test you want to run (ie, make test-common).

Using Nexus repository mirror with E2E testing

To speed up integration testing locally, you may use a Nexus Repository Manager for Maven repository mirror.

You can set the environment variable TEST_ENABLE_NEXUS=true to enable the usage of Nexus mirror in e2e testing. If TEST_ENABLE_NEXUS is set, e2e tests will try to discover a Nexus instance as nexus service in nexus namespace and if it is found they will use it as the Maven repository mirror for the camel-k platform under test.

TEST_ENABLE_NEXUS=true make test-integration

To set up a Nexus instance in your cluster, run the following command:

kubectl apply -f e2e/support/files/nexus.yaml
Back to top