I’ve written a bit about rspec-puppet in the past (directly here, here, and here, and indirectly here and here). The state of rspec-puppet has changed over the past year and change, though. Let’s see if we can collect the current practices in one place.

First, there’s a better way to deploy rspec-puppet than I wrote about earlier. If you’re implementing rspec-puppet brand new today, I suggest starting with puppet-module-skeleton as your base. If you’re upgrading an existing setup, take a closer look at the skeleton’s Gemfile, Rakefile, .rspec, .rubocop, spec/spec_helper.rb, /spec/spec_helper_acceptance.rb.erb, spec/classes/coverage_spec.rb, and spec/classes/example_spec.rb.erb and bring in the updates that are relevant. If you want to use hiera for your testing, I suggest adding these lines to spec/spec_helper.rb (PR submitted).

By using the Gemfile from puppet-module-skeleton, you can now use bundler to manage your gems instead of installing them globally on your nodes. Run bundle install first. You can then run the full suite of tests with bundle exec rake test, or simply run rspec with bundle exec rake spec_prep and rake spec_standalone. If you get into trouble, you can use git clean -fdx to remove all the untracked files, mostly from rspec fixtures.

Next is writing the tests. Writing rspec tests can be done with a few different matchers, but it { is_expected.[not_]to contain_<resource>(‘<resourcename>’) } is a common format. Of course, the officially documented matchers work just fine, though you may not see them in the wild very much. As for the tests themselves, always be sure that you are testing your code, and only your code. If you’re including a component module in your profile module, test that the component module is installed, but don’t test the component module’s resources – the module should have its own rspec tests. If it does not, add those tests to the component, not your profile. And of course, do not test Puppet itself – it also has rspec tests!

I do suggest using hiera instead of the :params symbol, though. This can help you design your hiera data while you work on rspec tests, to make sure you know what the hiera data should look like, not just what you think it should look like. Second, I think it is easier to set an additional top-level fact once, in the top describe block, than to set numerous params in each context block, though I believe you have to for defined types.

For general rspec guidance, check out Better Specs. It’s very helpful whether you’re writing tests for puppet or something else. I’ve also created a repository to track great examples of puppet module tests, broken down by area, called puppet-reference_modules. If you see a great example, please submit a PR!

These are the common practices as I understand and observe them. Is there anything I’ve missed or gotten wrong? Let me know!