Testing Patterns
Categories:
Etcha can test Patterns to ensure they actually work. Because of the nature of change
, check
, and remove
, testing is more or less free.
Performing Testing
You can test an entire path or specific files using etcha test
. Test will traverse directories and perform testing on all .jsonnet
files. Testing is performed by executing the Commands:
- Run all Commands in Change Mode (execute
check
, and if triggered,change
). Anychange
errors will cause testing to fail. - Run all Commands in Check Mode (execute
check
only). Anycheck
errors that would normally cause achange
to occur will cause testing to fail (check/command is not idempotent). - Run all Commands in Remove Mode (reverse order, execute
remove
). Anyremove
errors will cause testing to fail. - Run all Commands in Check Mode (execute
check
only). Any IDs that previously failedcheck
/changed during step 1 that do not failcheck
again will cause testing to fail.
By default, Etcha will only test run
Commands in a Pattern. To test build
Commands too, use the -b
flag: etcha test -b mydir
.
Testing is performed under the Config > sources
test
. It’s highly recommended to configure an alternative exec
configuration in here, such as a container, to avoid testing impacting a local system.
For Continuous Delivery/Continuous Integration Usage, it’s highly recommended to run testing across your entire Etcha codebase.
Candid Commentary
We use testing for all of our internal Patterns and Etcha’s LibrariesTest Mode
Linting and Testing both set a flag within vars passed to the Pattern, test
, to true
. You can retrieve this value within Jsonnet and adjust your Pattern files to render differently during test mode, i.e.:
// lib/mylib.libsonnet
local n = import '../etcha/native.libsonnet';
local config = n.getConfig();
{
check: (if config.test then '' else '[[ -d "/mydir" ]]'),
id: 'hello world',
}
In this example, check
will be an empty string in test mode.