Forum: RSpec Spec'ing a block

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

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 :)


Mvh
Morten Mller Riis

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, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak 
Hellesy)
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne

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

On Mon, Dec 5, 2011 at 9:13 AM, Morten Mller Riis
<mortenmoellerriis@gmail.com> 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.

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