Copyright 2020 Tim Sharpe
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
It’s been a while, but finally there’s a new release of rspec-puppet. Originally slated to be 0.2.0 but promoted to 1.0.0 due to a couple of backwards incompatible changes.
This deprecated matcher has been removed entirely now. If you still have code
using it, you should switch to using the generic contain_<resource>
matcher
instead.
This matcher has now been deprecated and will be removed in the next major release. The reason this is on it’s way out is that it doesn’t support parameterised classes and this has caused a lot of confusion for many users.
If you use include_class
anywhere, you’ll see the following depreciation
notice.
So, change:
1
it { should include_class('foo') }
To:
1
it { should contain_class('foo') }
In previous versions of rspec-puppet, parameter values were matched extremely
naively, where all values were flattened down to a string before comparison.
This means that ['b', 'ba']
would have been equal to ['bb', 'a']
for
example. As of 1.0.0, this behaviour has changed and we now compare data
structures like arrays and hashes correctly, so you may have to adjust your
tests accordingly.
Set the path to your hiera.yaml
file in your RSpec.configure
block and
you’re good to go.
1
2
3
4
RSpec.configure do |c|
# snip
c.hiera_config = '/path/to/your/hiera.yaml'
end
This new matcher should the be first thing in any rspec-puppet test suite. It checks that the catalogue will compile correctly and that there are no dependency cycles in the generated graph.
1
it { should compile }
This matcher also has a chain method to enable checking that all dependencies
in the catalogue have been met - with_all_deps
.
1
it { should compile.with_all_deps }
While at first glance, it might seem that this shouldn’t be optional however there are cases where you might not want to test this (if, for example, you are testing a module that notifies a resource in a different module).
Some new additions to the contain_<resource>
matcher are the resource
relationship tests.
1
2
3
4
it { should contain_file('foo').that_requires('File[bar]') }
it { should contain_file('foo').that_comes_before('File[bar]') }
it { should contain_file('foo').that_notifies('Service[bar]') }
it { should contain_service('foo').that_subscribes_to('File[bar]') }
Regardless of how you define your relationships, either using the
metaparameters (require
, before
, notify
and subscribe
) or the chaining
arrows (->
, <-
, ~>
and <~
) these tests will work.
Testing the reverse of the relationship described in your Puppet code will also work with these new methods. Take the following manifest for example:
1
2
3
4
notify { 'foo': }
notify { 'bar':
before => Notify['foo'],
}
Both of the following tests will work:
1
2
it { should contain_notify('bar').that_comes_before('Notify[foo]') }
it { should contain_notify('foo').that_requires('Notify[bar]') }
Also new to the contain_<resource>
matcher are the only_with
tests. Unlike
the with
tests which only test that the specified parameters have been
defined, only_with
tests that these are the only parameters passed to
a resource.
Like the with
tests, you can specify a single parameter with the
only_with_<parameter>
method:
1
it { should contain_service('ntp').only_with_ensure('running') }
Or, you can pass it a hash of parameters and values:
1
2
3
4
5
6
it do
should contain_service('ntp').only_with(
'ensure' => 'running',
'enable' => true,
)
end
The last new matchers for this release are have_resource_count
,
have_class_count
and the generic have_<resource>_resource_count
. As you
can guess, these matchers:
Count the total number of resources in the catalogue
1
it { should have_resource_count(3) }
Count the number of classes in the catalogue
1
it { should have_class_count(2) }
Count the number of resources of a particular type in the catalogue
1
it { should have_exec_resource_count(0) }
As always, if you find any bugs or have any suggestions for new functionality, please create an issue here.
Copyright 2020 Tim Sharpe
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.