Tests
Last updated
Last updated
You add Tests when you want Garden to run your test suites for you. A minimalistic configuration looks like this:
Garden caches Test results and only re-runs the Tests if the Test version changes. For remote environments, the test results are stored at the cluster level so that the entire team can share the cached results.
You use the 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.
You can run a Test manually with the garden test <test-name>
command. Append the --force
flag to rerun the Test even if it has previously passed.
You can view Test results by running garden get test-result <test-name>
.
The integ
test looks like this:
Many action types, including container
, exec
and helm
, allow you to extract artifacts after Tests have completed. This can be handy when you'd like to view reports or logs, or if you'd like a script (via a local exec
action, for instance) to validate the output from a Test.
Desired artifacts can be specified using the spec.artifacts
field on Test configurations. For example, for the container
Test, you can do something like this:
After running my-test
, you can find the contents of the report
directory in the test's container, locally under .garden/artifacts/my-test-report
.
Below is an example of a frontend-integ
Test that checks whether the frontend gets the correct response from the backend. The example is based on our .
Please look at individual to see how to configure each Run to extract artifacts.
In the , we'll see how Garden can execute tasks via Runs. For example populating a database after it has been deployed.