On Tue, Jul 25, 2017 at 3:15 PM, James Perry <[email protected]> wrote:
> So I am over thinking it then. I'm taking fact values from a list of > installed directories and removing the one matching the current version. > This is being used to remove the old install directories and I didn't want > it to whack the current version. I wanted to test that having the local > variable set to the current version causes the code to error out. Probably > not something that I need to test it seems. All of the versions come in via > a fact and are compared to the current version. > > I appreciate the input. I have the other tests for including the > associated modules to do the tasks testing out fine. > > Yeah, in that case the most appropriate thing to test is just that it's not trying to remove the current directory (e.g., no file resource ensure=absent for the current directory or whatever the mechanism is). The specific implementation isn't really important, and that means, for example, you could change it in some way so that it doesn't use the intermediate variable without having to change the test. > On Tuesday, July 25, 2017 at 5:59:50 PM UTC-4, Ryan Whitehurst wrote: >> >> On Tue, Jul 25, 2017 at 2:33 PM, James Perry <[email protected]> wrote: >> >>> I'm not sure if it can be done, but I am trying to test a case where I >>> take an array of values and use stdlib's delete to remove one value before >>> iterating over it. The class will fail if the removed value is present. >>> That all works fine except I am trying to write an rspec for it. Nothing I >>> have found seems to have a way I can figure out to do this. >>> >>> class my_class { >>> $var1 = ['a','b','c'] >>> $var2 = delete($var1, 'b') ==> Now ['a','c'] >>> >>> $var2.each |$var3| { >>> if $var3 == 'b' { >>> fail("Found b") >>> } >>> } >>> } >>> >>> I am trying to mock / stub is before testing do $var2 = ['a','b','c'] to >>> override the calculated $var2 from the delete function. >>> >>> What am I missing here? >>> >>> I tried let(:vars) {{ var2: ['a','b','c'] }}, which didn't work. >>> >>> Did a similar thing with a mock on my_class.new, but the value remained >>> as calculated by the class. >>> >>> Is it even possible to stub a local variable to the class / module to >>> force a failure condition? >>> >>> >> It doesn't make any sense to do this. If the variable is hardcoded, then >> there's no variation, so there's nothing to test. If the value is supposed >> to change, then it should be a parameter, not a hardcoded value. >> >> Between this and your previous rspec-puppet question, it appears the >> approach you're taking to testing is a bit weird. You seem to be trying to >> test the internals of how the classes work. That's not usually valuable, >> and frequently difficult, as you've noticed. Instead, think about the >> inputs a class or module takes and the results it produces. >> >> For your previous question, that's what the answer you got did. The >> inputs to foo were current_version and installed_version, and then based on >> those values, the result is either foo::cleanup was included in the catalog >> or it wasn't, so that's what you were recommended to test. >> >> For this, as written, there are no inputs, so your test would only have >> one condition: the class compiles. If $var1 is actually an input, either >> via a class parameter or a fact, then the result is either the catalog >> compiles or it fails with the specified error message, so you'd test by >> varying the input value and checking that it failed or compiled, as >> appropriate. >> >> Remember, tests are there to make sure that the code works as expected. >> The implementation details don't matter, just the behavior. If you try to >> test the implementation details, you're doing work that doesn't provide >> much value and makes it harder to refactor later. >> >> >>> Thanks! >>> >>> -- >>> 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/ms >>> gid/puppet-dev/10220b50-b89d-46a4-8a8f-b1cbfac87f2a%40googlegroups.com >>> <https://groups.google.com/d/msgid/puppet-dev/10220b50-b89d-46a4-8a8f-b1cbfac87f2a%40googlegroups.com?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 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/30121405-aa03-40ad-a22a-118bca58c260%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/30121405-aa03-40ad-a22a-118bca58c260%40googlegroups.com?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 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/CAHTHiAG7v0J%2BKDQupjoWZguxfBBknOy3gR%2BcR-VHg_i3yUN8yA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
