The hiera support in the 1.0.0 release is pretty rad, and makes it easy to test real hierdata and the side effects it can have.
Unfortunately, if you need to test error conditions for the "what if" scenarios, it can be a bit difficult. You basically have to add all sorts of extra hiera files to the cascade toggled by facts.
By automatically merging the contextual value of hierdata with the data pulled from hiera before catalog compilation, we can effectively keep all of the conditions required to test our code in the tests properly.
Imagine some Puppet code like this:
$backends = hiera('haproxy_backends', {})
if not has_key($backends, 'service1') or size($backends['service1']) == 0 {
fail('Could not find any service1 backends in haproxy config!')
}
if not has_key($backends, 'service2') or size($backends['service2']) == 0 {
fail('Could not find any service2 backends in haproxy config!')
}
Testing this currently involves jumping through all sorts of hoops as described above. Here's what testing could look like with hierdata overloading:
context "no service1 key" do
let(:hierdata) {
{
:haproxy_backends => {}
}
}
it { should_not compile }
end
context "service1 has no backends" do
let(:hierdata) {
{
:haproxy_backends => {
:service1 => []
}
}
}
it { should_not compile }
end
The hiera support in the 1.0.0 release is pretty rad, and makes it easy to test real hierdata and the side effects it can have.
Unfortunately, if you need to test error conditions for the "what if" scenarios, it can be a bit difficult. You basically have to add all sorts of extra hiera files to the cascade toggled by facts.
By automatically merging the contextual value of
hierdata
with the data pulled from hiera before catalog compilation, we can effectively keep all of the conditions required to test our code in the tests properly.Imagine some Puppet code like this:
Testing this currently involves jumping through all sorts of hoops as described above. Here's what testing could look like with hierdata overloading:
/cc @rodjek