CODEWITHSUNDEEP
puppethierarspec-puppet
Cory Ringdahl
Cory Ringdahl

Reputation: 542

How do I override hiera_data in rspec-puppet in puppet 6+?

Let's say I have a class that uses automatic hiera lookups:

class foo::file {
  file { $foo::file_name:
    owner  => $foo::owner,
    group  => $foo::group,
    ensure => $foo::ensure,
  }
}

The common.yaml for this module contains bindings for this:

foo::file_name: 'bar.txt'
foo::owner: 'user'
foo::group: 'user_group'
foo::ensure: 'present'

If I want to test this in rspec-puppet, how do I change the hiera data within the actual spec file? The only references I can find for this are in hiera-puppet-helper, which appears to be long abandoned, which looked like:

  let(:hiera_data) { { 'foo::file_name' => 'nope.txt' } }

Upvotes: 0

Views: 581

Answers (1)

John Bollinger
John Bollinger

Reputation: 180058

If I want to test this in rspec-puppet, how do I change the hiera data within the actual spec file?

You do not want to test that, specifically, in your spec tests. You are focusing too narrowly. The binding of Hiera data to class parameters is a function of the Puppet core, not of your classes, so you should not consider it in scope for your testing. What you seem actually to want to test is various combinations of parameter values for class foo, with that not being the class under test. Once you recognize that, you should also recognize that any means of assigning the wanted class parameter values will do the job. It doesn't have to be Hiera.

And there indeed is a viable alternative to using Hiera for the purpose: you can use a precondition to provide a resource-like declaration of class foo that expresses the wanted parameter values. And you need to provide some kind of declaration anyway if, as shown in the question, class foo::file does not provide for declaring foo itself. Example:

    let(:pre_condition) do
      <<-EOS
        class {'foo':
          file_name => 'bar.txt',
          owner     => 'user',
          group     => 'user_group',
          ensure    => 'present'
        }
      EOS
    end

I should not neglect at this point to add that resource-like class declarations should usually be avoided in your manifests. But the reasons for that are much less pronounced in the narrow scope and targeted use of a spec test.

I note also that the precondition approach does not conflict with the case where the class under test directly or indirectly executes an include-like declaration of class foo, as might very well happen in real-world cases. It would conflict if the class under test provided its own resource-like declaration of class foo, but it doesn't look like that would even be viable in cases like yours.

Additionally, be aware that your module-specific Hiera data is visible to the module's spec tests. You do not need to provide for that manually. You need the pre-condition or something like that only for testing data different from or in addition to the data already provided by your module.

And note that this does not address data that are directly looked up by your classes via the lookup() function or one of the hiera*() functions. For that, you need to set up bona fide Hiera data in your test fixture to test data other than your module-specific Hiera data.

Upvotes: 0

Related Questions