Add support for exported resource mocks

[saj]

Like what you have done with the fact mocks, but with exported resources.

This feature would kick arse.

[ghost]

Hi,

I would like to know how I can test if an exported resource has indeed been exported. Since this ticket in a year old, maybe there now is a way to do this ?

Thanks in advance

[hunner]

The current object against which rspec-puppet checks is the completely compiled catalog, which only contains exported resources that are realized with the <<| |>> collector.

When working on #51 I worked for a while on trying to verify that resources were actually exported, but the only way I could think is to create a node definition in spec/hosts that realizes the resources you want to check, then check there.

One possible solution: there is a :precondition block for manifest code that is added at the beginning of the test, so perhaps a :postcondition would give you the ability to add <<| |>> collectors for checking.

[lmayorga1980]

👍

[kjetilho]

this has been supported for a while, using a syntax like:

it do
  expect(exported_resources).to contain_nagios_host("foo.example")
                                .with_address("10.11.12.13")
end

(there may be more pretty ways of writing this as well)

[kjetilho]

What is still impossible, as far as I can tell, is to test the collection operator, ie. that the correct subset of exported resources are realized in your catalog.

If I read the code correctly, it is impossible to check whether collect works, since the <<| |>> collect code (LLCOLLECT) requires storeconfigs to be enabled to do any work at all. This in turn requires a working puppetdb-terminus.

I did manage to hack together a matcher for the exported property, and with that I could verify that my collect statement worked by using <| |> (LCOLLECT) instead (yes, this collects both @ and @@). Ie., my resources would be be visible in the catalog using the normal generic_contain, and I could use my .exported() matcher to verify the origin of this resource.

This is hardly a usable workaround, but it may point in a possible direction for implementation.