Is it a good idea to create helper ruby modules to be required by rspec-puppet tests?

asked 2017-08-10 12:50:04 -0500

I intend to do some changes in a number of templates for puppetlabs-apache module, and there will be an identical section repeated in all templates (in fact, included by a helper template, but this is irrelevant here). The rspec-puppet test for the classes which use these templates will, then have redundant code to test this content.
In order not to repeat code, I thought of creating a helper module with the redundant logic and requiring it in each spec test.

It would look kinda like:

# /spec/classes/mod/mod_helper_spec.rb
def repeated_content
  (Whatever redundant stuff)
end

# /spec/classes/mod/*_spec.rb
require './mod_helper_spec.rb'

(specifics for the tested class)

repeated_content(params)

(specifics for the tested class)

My question is: is this a Good Idea? The obvious intent is to DRY (don't repeat yourself) the test code, but I wonder if I'm adding more complexity than spec tests should have.
I read here and here about using this techique in plain Ruby rspec, but found no reference about this in rspec-puppet.

answered 2017-08-19 21:47:38 -0500

waveclaw
1 ●1

updated 2017-08-19 21:48:03 -0500

In my opinion, yes. This is a good idea.

rspec-puppet is still rSpec. That is, plain Ruby code. Using custom test modules to improve test code is not only good for DRY, but found in many of the "Rubyist" authored modules.

Other usefull tools for DRY test are:

These let you create test banks for any rSpec tests, including rspec-puppet tests.

Obviously there is also the rspec-puppet-facts you can use for some common Linux distribution facts.

Be aware that if you do create a fullRuby module it needs to be avaialble on the Ruby forge or some other source like GitLab.com or GitHub.com. If you are only developing in-house then you will need an in-house source for this code that other developers or admins or your CI system can access.

Otherwise when developers include the module in their Gemfile files it woud not be found and would break tests.

Do be aware that creating large test banks can lead to very large numbers of tests being run. Many of them may be duplicated and appear useless. But when a duplicated test fails the result can be an exictingly hard bug to resolve.