I didn't even realize this thread was old. Oops. I saw it come across email but I guess its how my email reader works.
On Friday, March 27, 2015 at 12:00:22 PM UTC-7, Trevor Vaughan wrote: > > 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] > <javascript:>> 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] <javascript:>. >> 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] <javascript:> > > -- 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/95e7d02d-cace-49ff-8d45-29f951ea62b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
