Spec'ing a block

Testing RSpec
1

Hi folks

How would you spec something like this:

as_user username do
  FileUtils.chmod_R 0755, "#{directory}/*"
end

Where as_user fires off a new process (and set uid to username).

It seems that this won’t catch FileUtils.chmod_R:

FileUtils.should_receive(:chmod_R).with(0755, “#{@domain.directory}/*”)

I guess that is because it is passed in the block and fired off in a
seperate process (Process.fork).

Mvh
Morten Mller Riis

2

For the moment I have done this:

def Process.fork(&block)
block.call
end

So that Process.fork doesn’t actually spawn a new process but just runs
it in the current one.

But any better suggestions are welcome :slight_smile:

Mvh
Morten Mller Riis

3

On 5 Dec 2011, at 12:04, Morten Mller Riis wrote:

It seems that this won’t catch FileUtils.chmod_R:

FileUtils.should_receive(:chmod_R).with(0755, “#{@domain.directory}/*”)

I guess that is because it is passed in the block and fired off in a seperate
process (Process.fork).

It depends on what you want to prove.

If you want to prove that this bit of code will set the actual flags on
the actual file, then why not let it do it, and then check that the file
ends up how you want it to? If it’s happening in a forked process,
you’ll need to wait for the process to close to be sure it’s done, but
otherwise that should be quite straightforward, and will give you
confidence that the whole thing is working.

Otherwise, you need to put a layer around the whole detail of forking
and running the FileUtils command, and put your mock assertion against
that layer. Right now you’re trying to introduce your mock into the
stuff that happens in the forked process, which isn’t going to work.

cheers,
Matt

–
Freelance programmer & coach
Author, Search (with Aslak
Hellesy)
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne

4

On Mon, Dec 5, 2011 at 9:13 AM, Morten Mller Riis
[email protected] wrote:

Hi Matt

Thank you for your reply!

I mock things like FileUtils for the following reasons: to avoid testing
FileUtils which I reckon has its own test suite and to avoid doing
potentially harmful things locally or having specs fail because of
insufficient permissions etc. I know the last bit could be worked out, but
for things like #rm_r I do like just to mock them.

Have you looked at FakeFS? It is faster than actually working on the
filesystem, and it avoids problems like accidentally deleting stuff.

5

FakeFS definitely looks like a nice solution!

I also like the argument about not tightly coupling the specs to File
and FileUtils.

Mvh
Morten Mller Riis

6

Hi Matt

Thank you for your reply!

I mock things like FileUtils for the following reasons: to avoid testing
FileUtils which I reckon has its own test suite and to avoid doing
potentially harmful things locally or having specs fail because of
insufficient permissions etc. I know the last bit could be worked out,
but for things like #rm_r I do like just to mock them.

Please let me know if this is not best practice. I know one can
“over-mock” a spec suite, but I generally tend to mock things that are
tested/spec’ed themselves.

Mvh
Morten Mller Riis