I am new to Mocha and writing unit tests in general so please do correct if
this is wrong.
I would think I should be able to test for the proper invocation of the
lgroupadd command vs. the groupadd command, even on a system that does not
contain the libuser package.
Doing some more looking around and reading, I came up with code which will
execute a test for the "forcelocal" parameter even on systems that do not
contain libuser. Since the command is not really being executed on the system,
just evaluated, this should cause no problems. I removed the libuser
capabilities from my machine and this test was still executed and passed
correctly.
it "should use luseradd instead of useradd when forcelocal=true" do
described_class.has_feature :libuser
resource[:forcelocal] = :true
provider.expects(:execute).with(includes('/usr/sbin/luseradd'))
provider.create
end
On Jan 18, 2013, at 2:38 AM, Dominic Cleal <[email protected]> wrote:
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
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
