> Thinking about it though (and after looking at the code), do you need the
>> little bit at the top there to be executed? Why can't you just do something
>> like:
>>
>> Puppet::Util.expects(:execute).with { |command,options| ... }
>>
>>
> This was the first approach I tried. There were three reasons it didn't
> work very well:
>
> 1. Puppet::Util is a module, which means that Mocha can't stub it out
> directly; you have to stub the individual classes that mix it in. That
> means that you have to use e.g.
> Puppet::Type::Mount::ProviderParsed.expects(:execute)..., which
> unfortunately makes the test more fragile because it only stubs out calls to
> Puppet::Util.execute() from that one particular class.
>
Doh! Right. I'd forgotten about that.
3. My primary purpose in creating this stubbing mechanism was to encourage
> people to write better integration tests for types and providers, by putting
> a simple state machine in the test that simulates the effect of the commands
> executed by the provider. Mocha's mechanism for writing state machines it
> quite clumsy, and after struggling with it for some time I realized that I
> didn't want to subject other test writers to it.
>
Ah, I see. So going back to my "have it do something" idea, maybe rather
than being "the thing that stubs execute" we should have it encapsulate the
common useage patterns for the FSM (that is, eventually expose an API
something like):
Puppet::Util::ExecutionStub('/sbin/mount') {
@mounted ? "/dev/disk1s1 on /Volumes/foo_disk (msdos, local)\n" : ""
}
Puppet::Util::ExecutionStub('/sbin/mount','-o','local','/Volumes/foo_disk')
{
# verify that we don't try to call "mount" redundantly
@mounted.should == false
check_fstab
@mounted = true
''
}
Puppet::Util::ExecutionStub('/sbin/umount','/Volumes/foo_disk') {
fail "unexpected umount" unless @umount_permitted
@mounted = false
''
}
To be clear this time, I'm not proclaiming that I have a better answer, just
>> expressing my hope that there is one.
>
>
> Thanks, Markus. My feeling is that in this case there isn't, but I'm open
> to further discussion. I'd be especially appreciative if you (or anyone
> else) wanted to take a shot at writing some type and provider integration
> tests using this mechanism, and see how well it works for you.
>
That's probably the best thing to do. Jeff, Dan & Nan were also expressing
interest in this space a few months ago.
Anyway, I'd like a smoother solution but I don't have one in stock, so these
comments shouldn't be construed as a argument against the patch but rather
an argument for continuing to find ways to improve the corner where rspec
meets execute meets the mount provider and it's ilk.
-- M
-----------------------------------------------------------
When in trouble or in doubt, run in circles,
scream and shout. -- 1920's parody of the
maritime general prudential rule
------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
