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. 

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] 
> <javascript:>> 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] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to