Skip to main content
Module authors can write end-to-end tests as Kubernetes Jobs that are run by Timoni, after the app workloads are deployed on a cluster. After the app workloads are installed and become ready, Timoni will apply the Kubernetes Jobs and will wait for the created pods to run to completion. On upgrades, Timoni will delete the previous test pods and will recreate the Jobs for the current module values and version.
IdempotencyTest runs are idempotent, if the module version and values don’t change, Timoni will not create new test pods. Tests are run only when a drift is detected in desired state.

Example

To demonstrate how tests work, we’ll add a Kubernetes Job that verifies that the app is accessible from inside the cluster, by running a curl command against the app’s service.

Test definition

Add the following CUE definition to the module’s templates directory:
We set the force annotation on the Job’s metadata to instruct Timoni to recreate the Job when it’s spec changes. And we compute the checksum of the module’s values that we set as an annotation on the Job’s pod template. This will trigger a Job recreation when the module version or values change.

Test configuration

To allows users to enable testing, we’ll add a test section to the module’s #Config definition:
In the module’s #Instance definition we’ll add the #TestJob to the tests list:
And finally we’ll configure Timoni to apply the tests objects in the timoni.cue file with:
Note that the apply: test section goes last, after the apply: app section. Timoni executes the apply sections in order, so the app workloads will be deployed first and then the tests will be applied.

Test execution

To verify that the test configuration works, enable testing in the module’s debug_values.cue file:
Running the vet command with the debug should print the test Job:
Running the apply command with the debug values should create the test Job, after the app workloads are deployed.