command
and args
directives to specify how the test is run. If the execution exits with 0, the test is considered to have passed, otherwise failed.--skip-tests
flag or, alternatively, specify what tests to run with the --test-names
flag.garden run test <test-name>
command. This will run the test regardless of whether or not the result is cached.garden get test-result <module-name> <test-name>
.frontend
module that has a unit
test and an integ
test that depends on a backend
module. The integ
test checks whether the frontend gets the correct response from the backend. The example is based on our vote example project.frontend
module:integ
test looks like this:frontend
, Garden will re-run both the unit
and integ
tests for you.backend
module, Garden will first re-build and re-deploy the backend
, and then run the integ
test defined for the frontend
.container
, exec
and helm
, allow you to extract artifacts after tests have been run. This can be handy when you'd like to view reports or logs, or if you'd like a script (via a local exec
module, for instance) to validate the output from a test.artifacts
field on test configurations. For example, for the container
module, you can do something like this:my-test
, you can find the contents of the report
directory in the test's container, locally under .garden/artifacts/my-test-report
.disabled: true
in the test configuration. You can also disable them conditionally using template strings. For example, to disable a container
module test for a specific environment, you could do something like this:garden-system--metadata
namespace with the format test-result--<hash>
and shared across the team.exec
module type runs tests locally in your shell. By default, the exec
module type executes tests in the Garden build directory (under .garden/build/<module-name>
). By setting local: true
, the tests are executed in the module source directory instead.serviceResource
needs to be specified to determine the pod spec for the test pod. You can see the whole pod spec used in the reference docs for kubernetes and helm modules. Please note that the startupProbe
, livenessProbe
and readinessProbe
are stripped from your pod spec. Health checks for your application might fail when the container is used for testing because the main process usually running in that container is replaced by the test command.