Testing your Operator project

Overview

The Operator SDK project recommends using controller-runtime’s envtest to write tests for your Operators projects. Envtest has a more active contributor community, it is more mature than Operator SDK’s test framework, and it does not require an actual cluster to run tests which can be a huge benefit in CI scenarios.

Using EnvTest

You will see that controllers/suite_test.go is created when a controller is scaffolded by the tool. This file contains boilerplate for executing integration tests using envtest with ginkgo and gomega. Setup instructions, including those for disconnected environments, are found here.

These tests are runnable as native Go tests:

go test controllers/ -v -ginkgo.v

The projects generated by using the SDK tool have a Makefile which contains the target tests which executes when you run make test. Note that this target will also execute when you run make docker-build IMG=<some-registry>/<project-name>:<tag>.

Operator SDK adopted this stack to write tests for its operators. It might be useful to check writing controller tests documentation and examples to learn how to better write tests for your operator. See, for example, that controller-runtime is covered by tests using the same stack as well.

e2e Integration tests

• For Golang-based operators: you can create the e2e tests using Go. See the test directory for the Memcached sample under the testdata/go/v3/memcached-operator to see an example of e2e tests.
• For Ansible-based operators: you can use Molecule, an Ansible testing framework. For further information see Testing with Molecule.
• For Helm-based operators: you can also use Chart tests.

Alternatively, you can achieve the same goal using shell scripts. The following are a few examples of shell scripts used for testing projects built with SDK 1.0.0:

• Legacy test to check Golang-based Operators
• Legacy test to check Helm-based Operators
• Legacy test to check Ansible-based Operators

Other Options

Also, you can write tests for your operator in a declarative format using kuttl. Via kuttl, you can define YAML manifests that specify the expected before and after states of a cluster when your operator is used. For more info see Writing Kuttl Scorecard Tests.

An alternative and more modern solution to kuttl is chainsaw. Chainsaw offers more flexibility, a rich assertion model, and is actively maintained. Tests from kuttl can be automatically converted to chainsaw, see Migration from KUTTL.

To implement application-specific tests, the SDK’s test harness, scorecard, provides the ability to ship custom code in container images as well, which can be referenced in the test suite. Because this test suite definition metadata travels with the Operator Bundle, it allows for functional testing of the Operator without the source code or the project layout being available. See Writing Custom Scorecard Tests.