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 M?ller 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 M?ller Riis On Dec 5, 2011, at 1:04 PM, Morten M?ller Riis wrote:> 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 M?ller Riis > > >
On 5 Dec 2011, at 12:04, Morten M?ller Riis wrote:> 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).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 Helles?y) 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 M?ller Riis On Dec 5, 2011, at 3:39 PM, Matt Wynne wrote:> > On 5 Dec 2011, at 12:04, Morten M?ller Riis wrote: > >> 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). > > > 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 Helles?y) > Founder, http://relishapp.com > +44(0)7974430184 | http://twitter.com/mattwynne > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20111205/b446a6ef/attachment.html>
On Mon, Dec 5, 2011 at 9:13 AM, Morten M?ller Riis <mortenmoellerriis at 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.> 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 M?ller Riis > > > > On Dec 5, 2011, at 3:39 PM, Matt Wynne wrote: > > > On 5 Dec 2011, at 12:04, Morten M?ller Riis wrote: > > 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). > > > > 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 > Helles?y) > Founder, http://relishapp.com > +44(0)7974430184 | http://twitter.com/mattwynne > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
FakeFS definitely looks like a nice solution! I also like the argument about not tightly coupling the specs to File and FileUtils. Mvh Morten M?ller Riis On Dec 5, 2011, at 6:21 PM, David Chelimsky wrote:> On Mon, Dec 5, 2011 at 9:13 AM, Morten M?ller Riis > <mortenmoellerriis at 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. > >> 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 M?ller Riis >> >> >> >> On Dec 5, 2011, at 3:39 PM, Matt Wynne wrote: >> >> >> On 5 Dec 2011, at 12:04, Morten M?ller Riis wrote: >> >> 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). >> >> >> >> 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 >> Helles?y) >> Founder, http://relishapp.com >> +44(0)7974430184 | http://twitter.com/mattwynne >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20111206/2a90ad98/attachment.html>