Thanks for the reference. Note that RuboCop had a problem with the style; I'll push a patch presently.
On Wednesday, February 17, 2016 at 10:30:06 AM UTC-5, Trevor Vaughan wrote: > > 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 > > On Wed, Feb 17, 2016 at 10:11 AM, Joseph Wilkicki <[email protected] > <javascript:>> wrote: > >> 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. >> >> On Tue, Feb 16, 2016 at 5:27 PM, Felix Frank < >> [email protected] <javascript:>> wrote: >> >>> 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 >>> >>> >>> On 01/27/2016 11:27 PM, [email protected] <javascript:> wrote: >>> >>> 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! >>> >>> >>> -- >>> 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 >>> [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-users/56C3A253.70303%40Alumni.TU-Berlin.de >>> >>> <https://groups.google.com/d/msgid/puppet-users/56C3A253.70303%40Alumni.TU-Berlin.de?utm_medium=email&utm_source=footer> >>> . >>> >>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/CAFwCtQRmBuX8vzdYcz1hixx4AgOAqQNpG4mT6-_%3DqoGN71mn7Q%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/puppet-users/CAFwCtQRmBuX8vzdYcz1hixx4AgOAqQNpG4mT6-_%3DqoGN71mn7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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 -- > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/64eadf2b-19b7-41d0-8d71-4bdb593d9419%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
