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/CAHTHiAHUSaC3esuhGtLeJaPQwHuL4TzKBu2fU7rasUQtMAHRtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
