Trying to understand stubbing in the examples

[russellshackleford]

While looking at the README and then looking at the panos, apt, meraki, and hue_rsapi examples, all of them stub provider and then disable the rubocop test for stubbing it. I'm not very familiar with rspec, but I'm wondering: is there an alternative manner of injecting dummy data so that the return from the real method call is actually tested?

[Thomas-Franklin]

In general it is best not to be stubbing the subject under test which is why the rule is enabled by default.

The examples which you have mentioned are an exception to the rule due to the code structure being tested.

For example in the panos module, especially around the base providers; they stub the provider as the base provider does not have the xml_from_should and validate_should methods, as these methods are contained within the actual providers and tested within the the unit tests specific to them.

Using the panos module as an example again; for the panos_tag type the xml_from_should tests can be found here: https://github.com/puppetlabs/puppetlabs-panos/blob/master/spec/unit/puppet/provider/panos_tag/panos_tag_spec.rb#L88-L147 which makes use of a shared_example to reuse the test cases across the providers: https://github.com/puppetlabs/puppetlabs-panos/blob/master/spec/support/shared_examples.rb#L1-L7

It is this separation which meant that in the PanosProvider the calls to xml_from_should etc. are stubbed as we do not need to worry about the actual values at that level, as the methods are tested within the implemented provider's unit tests.

Testing the behaviour of a real method call would be moving more in to integration/acceptance level testing which can be done in a variety of ways, it is nicely explained in a presentation by my colleague @DavidS : https://www.netways.de/index.php?id=3445#c44135 especially around slides 16 onwards which goes in to detail on thoroughly testing the providers behaviour.