Wow, thread resurrection! I figured out how to solve my problem but thanks for the pointers to the additional tools, quite useful.
I also ended up dumping variables either through Pry or through a function. The issue that I was having is that I have some functions that modify items on the filesystem itself and needed to work around that. I ended up refactoring the functions to make everything properly variable which solved the issue for temporary testing scenarios. Thanks, Trevor On Fri, Mar 27, 2015 at 2:38 PM, Corey Osman <[email protected]> wrote: > Coming from regular language testing your first thought with puppet is how > do I control the flow of code when testing. In normal languages you can > mock the functions, getters, setters and possibly instance variables. With > puppet its a bit different. > > You can control the flow of puppet code only by influencing puppet facts > and class / define parameters, and a few other things. You can also mock > functions as well but generally you don't need to. > > Since the rspec-puppet subject is always the compiled catalog, everything > your testing against must be or not be in the catalog. Rspec-puppet > compiles that catalog and each test you make checks that the end result of > the catalog compilation with your influenced facts and parameters. Don't > be concerned with checking variable content explicitly, since all variables > will be present in some other resource or template that you can test > against. And yes you can test the rendered template for specific content. > > What this usually means is that given a conditional block you need to test > against the resource that contains your variable with a negative and > positive test. > > Example puppet code: > > if $::osfamily == 'RedHat' { > notify{"Hello from Conditional block":} > > } > > ## Test code > > describe :RedHat do > let(:facts) {{ :osfamily => 'RedHat'}} > it { should contain_notify('Hello from Conditional block') } > > end > describe :Windows do > let(:facts) {{ :osfamily => 'Windows'}} > it { should_not contain_notify('Hello from Conditional block') } > > end > > > Remember that your testing against the compiled catalog which either > should or should_not contain the resource. > > Now if you just want to see what is inside your variable you can use the > dump_args function to output the variable, write a notify resource or use > the inline template function. I wrote this a while ago to making dumping > variables to STDOUT easy. > > > https://github.com/logicminds/puppetlabs-stdlib/blob/63a1e75ef91865903945b7d2083ae293dadf6104/lib/puppet/parser/functions/dump_args.rb > > dump_args($var1, $var2, $var3, ...) > > Also for mocking functions I would recommend using the following gem. > https://github.com/Accuity/rspec-puppet-utils > > Lastly, if you want your module to be setup automatically for testing, in > addition to automated test generation, you should check this out. > https://github.com/logicminds/puppet-retrospec > > > Corey > > On Friday, March 28, 2014 at 7:39:59 AM UTC-7, Trevor Vaughan wrote: >> >> Hopefully I didn't just overlook this in the docs but, in rspec-puppet, >> how would you go about getting the value of $bar from the following? >> >> class foo { >> $bar = interesting_function('baz') >> } >> >> I've inspected everything that I think is obvious and I don't want to try >> and stub what 'interesting_function' should be doing since it's dynamic. >> >> Any ideas? >> >> Thanks, >> >> Trevor >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> [email protected] >> >> -- This account not approved for unencrypted proprietary information -- >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" 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-dev/f0e2d811-c10d-443c-b756-49f7a4c4fc5c%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/f0e2d811-c10d-443c-b756-49f7a4c4fc5c%40googlegroups.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 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev/CANs%2BFoXyRGxXcNRLT%2BU9e9dqPxPoivnZ6QGHKdW-oujpJYK%3DxQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
