On Tue, Oct 12, 2010 at 12:48 PM, Markus Roberts <[email protected]>wrote:
>
>
> diff --git a/spec/unit/provider/user/user_role_add_spec.rb
>>>> b/spec/unit/provider/user/user_role_add_spec.rb
>>>> index b3244f1..cc4fd9a 100644
>>>> --- a/spec/unit/provider/user/user_role_add_spec.rb
>>>> +++ b/spec/unit/provider/user/user_role_add_spec.rb
>>>> @@ -67,12 +67,12 @@ describe provider_class do
>>>> @provider.create
>>>> end
>>>>
>>>> - it "should set password age rules" do
>>>> + it "should set password age rules with passwd" do
>>>> @resource = Puppet::Type.type(:user).new :name => "myuser",
>>>> :password_min_age => 5, :password_max_age => 10, :provider =>
>>>> :user_role_add
>>>> @provider = provider_class.new(@resource)
>>>> @provider.stubs(:user_attributes)
>>>> @provider.stubs(:execute)
>>>> - @provider.expects(:execute).with { |cmd, *args| args == ["-m", 5,
>>>> "-M", 10, "myuser"] }
>>>> + @provider.expects(:execute).with { |args| args ==
>>>> ["/usr/bin/passwd","-n", 5, "-x", 10, "myuser"] }
>>>> @provider.create
>>>> end
>>>> end
>>>> --
>>>> 1.7.0.4
>>>>
>>>>
>> +1 to the fix, but not the spec change. Because providers validate the
>> existence of their commands, this spec will now fail on any system which
>> doesn't have a /usr/bin/passwd command. It will return "nil" for the command
>> name, which is why the previous version of the spec was only checking the
>> arguments. I suppose a possibility is to confine the spec to Solaris, which
>> gives some validation that the command is correct for that system.
>>
>
> So how should we test (in a testing environment neutral way) that
> user_role_add correctly tries to use passwd instead of chage? In other
> words, how should we test that this fix isn't regressed in some way, rather
> than saying "well, the code we are trying to test gives inconsistent results
> depending on who runs the test, so we just don't test that part"?
>
>
Given the way that commands are set and validated, which happens when the
type is first used, I can't really see a way to intercept that from this
test (or even from this file). So the command will be nil long before it
ever gets to us. So the only test I can see being viable across environments
is to stub the command method to return some particular known value, which
tells us at least that it is using the command we specified to be the
"password" command. Beyond that, we would probably need to have a
Solaris-specific test telling us that the command being used is what we
think it should be, and that the command actually exists on Solaris. The
latter part is key, as that is the only part of this idea which actually
could have caught the particular bug it's trying to verify as fixed.
> -- M
> -----------------------------------------------------------
> The power of accurate observation is
> commonly called cynicism by those
> who have not got it. ~George Bernard Shaw
> ------------------------------------------------------------
>
> --
> 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]<puppet-dev%[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.
