chefspec does not allow stubbing block style guards, it does allow command
/ string style gurards. If you change the guard to use test -e file (and
from your example, it looks you can) then you use stub_command("test -e
file").and_return(true) or false depending upon your use case
On Wed, Oct 29, 2014 at 3:21 PM, Joe Nuspl nuspl@nvwls.com wrote:
I’m automating some 3rd party code. What I have is something like:
execute ‘refresh’ do
only_if { CONDITION }
end
execute ‘reconfigure' do
only_if { ::File.exists?(GUARD) }
end
Sometimes refresh creates GUARD. GUARD could also be created by an admin.
reconfigure removes GUARD upon success.
I am try to write chefspec tests to cover all the cases:
no-existing-guard refresh-creates-gaurd
no-existing-guard refresh-does-not-create-guard
existing-guard refresh-creates-guard
existing-guard refresh-does-not-create-guard
no-existing-guard no-refresh
exisiting-guard no-refresh
What I want to do is to “hook” into execute[refresh] and conditionally
update the ::File.exists? stub to return true.
If I update the stub before the run, I’ve collapsed #1 and #4 into one
case.
Is it possible to hook into a resource? I tried :step_into but that did
not seem to do the trick. Any guidance would be appreciated.
Stubbing of block style guards seems to work for me:
before do
allow(File).to receive(:exists?).and_call_original
allow(File).to receive(:exists?).with('/tmp/guard').and_return(true)
end
But that was not this issue I was describing. I was wondering if there was a way to run some code after the runner processed “execute[refresh]” but before “execute[reconfigure]”.
chefspec does not allow stubbing block style guards, it does allow command / string style gurards. If you change the guard to use test -e file (and from your example, it looks you can) then you use stub_command("test -e file").and_return(true) or false depending upon your use case
On Wed, Oct 29, 2014 at 3:21 PM, Joe Nuspl nuspl@nvwls.com wrote:
I’m automating some 3rd party code. What I have is something like:
execute ‘refresh’ do
only_if { CONDITION }
end
execute ‘reconfigure' do
only_if { ::File.exists?(GUARD) }
end
Sometimes refresh creates GUARD. GUARD could also be created by an admin. reconfigure removes GUARD upon success.
I am try to write chefspec tests to cover all the cases:
no-existing-guard refresh-creates-gaurd
no-existing-guard refresh-does-not-create-guard
existing-guard refresh-creates-guard
existing-guard refresh-does-not-create-guard
no-existing-guard no-refresh
exisiting-guard no-refresh
What I want to do is to “hook” into execute[refresh] and conditionally update the ::File.exists? stub to return true.
If I update the stub before the run, I’ve collapsed #1 and #4 into one case.
Is it possible to hook into a resource? I tried :step_into but that did not seem to do the trick. Any guidance would be appreciated.
you can and_return(true, false) to return a sequence of a values...
that doesn't answer your question, but i think that's what you're
trying to do?
On Thu Oct 30 11:16:51 2014, Joe Nuspl wrote:
Stubbing of block style guards seems to work for me:
before do
allow(File).to receive(:exists?).and_call_original
allow(File).to receive(:exists?).with('/tmp/guard').and_return(true)
end
But that was not this issue I was describing. I was wondering if
there was a way to run some code after the runner processed
“execute[refresh]” but before “execute[reconfigure]”.
chefspec does not allow stubbing block style guards, it does allow
command / string style gurards. If you change the guard to use test -e file (and from your example, it looks you can) then you use
stub_command("test -e file").and_return(true) or false depending upon
your use case
I’m automating some 3rd party code. What I have is something like:
execute ‘refresh’ do
only_if { CONDITION }
end
execute ‘reconfigure' do
only_if { ::File.exists?(GUARD) }
end
Sometimes refresh creates GUARD. GUARD could also be created by
an admin. reconfigure removes GUARD upon success.
I am try to write chefspec tests to cover all the cases:
1) no-existing-guard refresh-creates-gaurd
2) no-existing-guard refresh-does-not-create-guard
3) existing-guard refresh-creates-guard
4) existing-guard refresh-does-not-create-guard
5) no-existing-guard no-refresh
6) exisiting-guard no-refresh
What I want to do is to “hook” into execute[refresh] and
conditionally update the ::File.exists? stub to return true.
If I update the stub before the run, I’ve collapsed #1 and #4
into one case.
Is it possible to hook into a resource? I tried :step_into but
that did not seem to do the trick. Any guidance would be
appreciated.
Thanks.
Joe
that doesn't answer your question, but i think that's what you're trying to do?
On Thu Oct 30 11:16:51 2014, Joe Nuspl wrote:
Stubbing of block style guards seems to work for me:
before do
allow(File).to receive(:exists?).and_call_original
allow(File).to receive(:exists?).with('/tmp/guard').and_return(true)
end
But that was not this issue I was describing. I was wondering if
there was a way to run some code after the runner processed
“execute[refresh]” but before “execute[reconfigure]”.
chefspec does not allow stubbing block style guards, it does allow
command / string style gurards. If you change the guard to use test -e file (and from your example, it looks you can) then you use
stub_command("test -e file").and_return(true) or false depending upon
your use case