I’m speccing a small lib which manipulates image files using
mini_magick.
The lib creates various temporary files during the process, the lib then
cleans up the temporary files at the end.
I’m trying to mock expectations that the calls are made to File#delete
[’-full’,’_screen’,’_shadow’,’_back_shadow’].each do |f|
File.delete “#{tmp_path}#{f}.png” if File.exists? “#{tmp_path}#{f}.png”
end
end
…
end
The expectations work fine, however, I also have an after block which
also calls File.delete to clean up the final version of the manipulated
test image
after(:each) do
cleanup manipulated image
File.delete out_dir.join(‘MenuIcon.png’) if File.exists?
out_dir.join(‘MenuIcon.png’)
end
The File.delete call in the after block fails because its calling the
mocked version of File.delete
This results in the following error:
My next step was to stub the write method for every instance of
MiniMagick::Image
However I will then no longer be able to test the cleanup because the
delete method will never be called if the files don’t exist.
I’m pretty sure I’m going about this the wrong way and making it
difficult for myself here.
Appreciate any help & feedback
[‘-full’,‘_screen’,‘_shadow’,‘_back_shadow’].each do |f|
after(:each) do
out_dir.join(‘MenuIcon.png’)
I’m pretty sure I’m going about this the wrong way and making it difficult http://rubyforge.org/mailman/listinfo/rspec-users
Give File.unstub(:delete) in your after block.
This email and any files or ideas transmitted within it are sent in
confidence and are intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error please notify the system manager at [email protected]
Thanks Justin,
That isnt working… its erroring with:
The method delete was not stubbed or was already unstubbed
Hi Rob
For reasons I could go into, when I’m coding myself I don’t usually stub
out file system access or other third party systems. Rather, I write an
adapter that behaves in the way I expect and test it using the real file
system, then test the rest of the system against a mock. That avoids
this category of problem.
What you’re doing here appears to be mixing both real (from mini_magick)
and stubbed (your own library’s) calls to filesystem code, and I think
it’s the asymmetry that’s biting you.
I could explain the above in more detail*, but in lieu of that, here’s
another angle: can you run the code in a subdirectory per image and nuke
that after? That way you only have one point to hit for the cleanup.
HTH
Ash
As a quick example, you might have a TempFileCleaner object in place
of IconGenerator#cleanup, seeded with all the potential temp filenames,
or some algorithm to figure them out
The method in the lib that does this is:
File.delete “#{tmp_path}#{f}.png” if File.exists? “#{tmp_path}#{f}.png”
end
However I will then no longer be able to test the cleanup because the delete
method will never be called if the files don’t exist. [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
Hi Rob,
First of all perhaps you are testing the wrong thing in the wrong place.
As cleanup is a private method, why are you specifying (in this spec
how it works). As far as IconGenerator is concerned currently all you
care about is that it calls cleanup. You’re not interested in how that
cleanup is implemented. If you want to specify how the cleanup works
then make cleanup public - either in this class, or perhaps better yet
in another class. e.g.
describe “Cleanup.clean”
it “should delete files”
end
…
end
describe IconGenerator
…
it should cleanup
Cleanup.should_receive(:clean) …
end
Once you separate the cleanup spec from the IconGenerator spec then
the clash should disappear! You’ll never have to mock File.delete
I thought that too, but then it occurred to me there’s a chance
mini_magick isn’t using Ruby’s filesystem code (it might be writing to
the FileSystem with native code for example), so I didn’t put this in to
confuse the situation. But yes, if it could be done, FakeFS might work
well here.