Problems testing branching using rspec-puppet with hiera

[jwil...@gmail.com]

Hi all!

I've been banging my head against this for the past couple of days and I'm pretty stuck.  I've started implementing rspec tests for a class that uses a hiera lookup and then uses the looked up value to control part of its logic.  A simplified version:

class mytest {

  

     $mycondition = hiera('my::condition')

     if $mycondition {

         ...

     }

}

My spec_helper looks like this:

require 'rubygems'

require 'puppetlabs_spec_helper/module_spec_helper'

RSpec.configure do |c|

  c.hiera_config = 'spec/fixtures/hiera/hiera.yaml'

end

So far, so standard.   What I want to be able to test, obviously, is making sure that when $mycondition is true, the resources in the if statement are added to the catalog, and if $mycondition is false, they aren't.

So, my spec in spec/classes/mytest_spec.rb looks like this:

require 'spec_helper'

describe 'mytest' do

  let(:node) { 'truecondition' }

  if {

    should compile

  }

end

My hiera.yaml file looks like this:

---

 :backends:

    - yaml

 :yaml:

   :datadir: 'spec/fixtures/hieradata'

 :hierarchy:

   - "%{::fqdn}"

and my spec/fixtures/hieradata/truecondition.yaml looks like this:

---

  my::condition: false

With this setup, my spec class returns an error:

Failures:

  1) mytest should compile into a catalogue

without dependency cycles

     Failure/Error: should compile

       error during compilation: Evaluation Error: Error while evaluating a Func

tion Call, Could not find data item my::condition in any Hiera data file

 and no default supplied at C:/puppet/mytest/spec/fixtures/modules/mytest/manifests/init.pp:3:22 on node truecondition

     # ./spec/classes/mytest_spec.rb:7:in `block (2 levels) in

<top (required)>'

Finished in 0.4212 seconds (files took 2.42 seconds to load)

1 example, 1 failure

Ultimately, I thought I could specify a different context for each state of $mycondition: true and false, so my test would look like:

require 'spec_helper'

describe 'mytest' do

   context "with mycondition => true" do

       let(:node) { 'truecondition' }

       if {

            should compile

       }

   end

   context "with mycondition => false" do

       let(:node) { 'falsecondition' }

       if {

            should compile

       }

   end

end

I tried having my contexts set a fact that hiera could use to select which yaml file it got data from: didn't work.  I tried having a different hiera.yaml file, one for true and one for false, that would load a different common.yaml (since common.yaml seems to work, but nothing else), and that didn't work.  The example above was the last thing I tried, since rspec-puppet is supposed to provide the fqdn fact, so I thought setting the node might help it switch. Failure on all sides!

I'm trying to do this because we've tried to write our profiles following the practice of doing hiera lookups instead of class parameters, as recommended here:  http://garylarizza.com/blog/2014/10/24/puppet-workflows-4-using-hiera-in-anger/

At this point, I'm almost ready to throw in the towel.  There has to be some way to change what values hiera supplies so I can test all branches of my code, but I'm not sure how to do it.  Any suggestions or alternatives would be welcome.

Thanks!

[Kalai A]

Share me the file path hiera.yaml  and ".yaml" file where you kpet under /spec directory.

[Felix Frank]

Hi,

I don't really have an answer for you, but would it be a feasible workaround for you to convert your variable lookup into a class parameter that is looked up implicitly? This way, you can just exploit rspec-puppet's own facilities for providing test input, and need not perform the whole Hiera dance (it's supposed to be a unit test, after all - you're grazing integration test level there).

HTH,
Felix

[Joseph Wilkicki]

It isn't really feasible to convert to a class parameter since I'm testing profiles which, as I understand it, should not be using class parameters.  I've since found a solution that seems like it might work;  I've been working on other topics for a bit, but when I get back to it I'll post some example code to this thread in the hopes that others might find it useful.

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/QRK6MJsN6fY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/56C3A253.70303%40Alumni.TU-Berlin.de.

For more options, visit https://groups.google.com/d/optout.

[Trevor Vaughan]

Hi Joseph,

You can see how we do it in SIMP using this reference spec_helper.rb https://github.com/simp/pupmod-simp-simplib/blob/master/spec/spec_helper.rb.

The way it's set up allows you to use variables to change your hieradata on the fly and can use the context name to pick hiera data files automatically.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAFwCtQRmBuX8vzdYcz1hixx4AgOAqQNpG4mT6-_%3DqoGN71mn7Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --

[Bob Vincent]

Thanks for the reference.   Note that RuboCop had a problem with the style; I'll push a patch presently.

To unsubscribe from this group and all its topics, send an email to puppet...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/56C3A253.70303%40Alumni.TU-Berlin.de.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAFwCtQRmBuX8vzdYcz1hixx4AgOAqQNpG4mT6-_%3DqoGN71mn7Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.