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 <jwil...@gmail.com > <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 < >> felix...@alumni.tu-berlin.de <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, jwil...@gmail.com <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 >>> puppet...@googlegroups.com <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 puppet...@googlegroups.com <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 puppet-users+unsubscr...@googlegroups.com. 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.
