On 18/01/13 07:30, John Julien wrote:
> Hi,
> I'm adding the feature :libuser to Puppet::Type::Group. In the groupadd
> provider, having the feature libuser and setting forcelocal => true will
> cause the invoked command to be lgroupadd instead of groupadd. I want
> to write a test case for both when the libuser feature is present and
> when its not.
>
> I'm seeing a lot of test cases written like:
> describe "on system that feature system_groups", :if =>
> described_class.system_groups? do
>
> This appears to restrict the test case from being run only on systems
> that actually support the system_groups feature. I would like to write
> a test case that, within the groupadd provider, emulates both having and
> not having the libuser feature and making sure that the command
> lgroupadd and groupadd are used respectively.
>
> I thought I could accomplish this by executing
> provider.stubs(:feature?).with(:libuser).returns(true)
>
> But I end up getting unexpected invocation errors because
> provider.features? gets executed by Puppet::Type::Group with other
> parameters than :libuser.
The method you want to stub is actually on Puppet.features:
has_feature :libuser if Puppet.features.libuser?
So you'd be using:
Puppet.features.expects(:libuser?).returns(true)
The trouble in this case, and the reason I think the other tests only
run on systems with those features, is that *provider* features aren't
re-evaluated at all.
This is logged as issue #2384, but it's mostly a problem for libraries
which can be installed during a run and require re-evaluation of features.
When the provider is initially evaluated, the if feature statement is
going to get evaluated, but not again. This means if you come to stub
the *system* libuser feature in the test harness, it won't change the
evaluation that's already happened for the provider's feature.
I think if you're going to implement this as a provider feature, you'll
have to test it in a similar way to system_groups.
--
Dominic Cleal
Red Hat Engineering