The Joy of Snow and Seasons

I love the changes the seasons bring. The warmth and rebirth of spring, the long days and sunshine of summer, the cooling temperatures and changing leaves of fall, and the snow and shorter daylight of winter. In particular, I really, really love the snow. I love watching it snow, I love the dogs playing in it, and it’s great football weather. Sure, I don’t love raking leaves and shoveling snow, but the benefits far outweigh these negatives.

This may seem an odd thing to wax poetic about, but my wife and I grew up in the MidWest and North, respectively, and spent almost a decade in the South. We really missed the seasons when we were in North Carolina, where the summer is about 9-10 months long. Living in Eastern VA was a bit better, the seasons were closer to 3 months each and we got snow a few times, but it was rare enough that you’d have to be crazy to drive in it. We’re now in Indiana, where the seasons are seasonal and snow is just something that happens.

This past weekend was the first snow of the season, which was really fun. I even got to play some flag football in it which is amazingly fun. I love me some snow!

Modern rspec-puppet practices

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!