rspec users - Sep 2008 - mocking the shell command (Kernel module)

hello there,
what is the best (or any) way of mocking the running of shell commands?

e.g.
code like the following:

%{ ls }

spec:

it "should list the directory contents"
  shell = mock(Object) # %{} lives in Kernel module and its sugar for `

end
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080912/88e9d1bb/attachment.html>

ooopssss, sorry the last one goes out unfinished (some gmail hotkey)...

hello there,
what is the best (or any) way of mocking the running of shell commands?

e.g.
code like the following:

def method
  %{ ls }
end

spec:

it "should list the directory contents"
  shell = mock(Object) # %{} lives in Kernel module and its sugar for `
  shell.should_receive(:`).with(:ls)
end

sorry about latter one, thanks in advance
joaquin

2008/9/12 Joaquin Rivera Padron <joahking at gmail.com>
> hello there,
> what is the best (or any) way of mocking the running of shell commands?
>
> e.g.
> code like the following:
>
> %{ ls }
>
> spec:
>
> it "should list the directory contents"
>   shell = mock(Object) # %{} lives in Kernel module and its sugar for `
>
> end
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080912/e0fea507/attachment.html>

On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
> what is the best (or any) way of mocking the running of shell  
> commands?
>
> e.g.
> code like the following:
>
> def method
>   %{ ls }
> end
>
> spec:
>
> it "should list the directory contents"
>   shell = mock(Object) # %{} lives in Kernel module and its sugar  
> for `
>   shell.should_receive(:`).with(:ls)
> end
>
> sorry about latter one, thanks in advance
> joaquin
I suggest you put a ''seam'' between your code and the call the
Kernel.

See Pat''s excellent answer to a similar question in this thread:
http://www.ruby-forum.com/topic/164893#new

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080912/8f958aee/attachment.html>

thanks,
I''ll give that a try

joaquin

2008/9/12 Matt Wynne <matt at mattwynne.net>
> On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
>
> what is the best (or any) way of mocking the running of shell commands?
>
> e.g.
> code like the following:
>
> def method
>   %{ ls }
> end
>
> spec:
>
> it "should list the directory contents"
>   shell = mock(Object) # %{} lives in Kernel module and its sugar for `
>   shell.should_receive(:`).with(:ls)
> end
>
> sorry about latter one, thanks in advance
> joaquin
>
>
> I suggest you put a ''seam'' between your code and the call
the Kernel.
>
> See Pat''s excellent answer to a similar question in this thread:
> http://www.ruby-forum.com/topic/164893#new
>
> cheers,
> Matt
> ----
> http://blog.mattwynne.net
> http://songkick.com
>
> In case you wondered: The opinions expressed in this email are my own and
> do not necessarily reflect the views of any former, current or future
> employers of mine.
>
>
>
>
> _______________________________________________
> 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/20080912/7ca28c80/attachment-0001.html>

On Sep 12, 2008, at 9:29 AM, Matt Wynne wrote:
> On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
>
>> what is the best (or any) way of mocking the running of shell  
>> commands?
>>
>> e.g.
>> code like the following:
>>
>> def method
>>   %{ ls }
>> end
>>
>> spec:
>>
>> it "should list the directory contents"
>>   shell = mock(Object) # %{} lives in Kernel module and its sugar  
>> for `
>>   shell.should_receive(:`).with(:ls)
>> end
>>
>> sorry about latter one, thanks in advance
>> joaquin
>
> I suggest you put a ''seam'' between your code and the call
the Kernel.
That sounds like a good idea.  You can also Kernel#` directly (instead  
of `foo` call Kernel.send(:`, "foo").  This allows you to stub out  
Kernel#`.

Scott

hi,
this did the trick:

  class Shell
    def self.sh command
      %{ command }
    end
  end

then I am able to:

it "should be mock alright" do

end

2008/9/13 Scott Taylor <mailing_lists at railsnewbie.com>
>
> On Sep 12, 2008, at 9:29 AM, Matt Wynne wrote:
>
>  On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
>>
>>  what is the best (or any) way of mocking the running of shell
commands?
>>>
>>> e.g.
>>> code like the following:
>>>
>>> def method
>>>  %{ ls }
>>> end
>>>
>>> spec:
>>>
>>> it "should list the directory contents"
>>>  shell = mock(Object) # %{} lives in Kernel module and its sugar
for `
>>>  shell.should_receive(:`).with(:ls)
>>> end
>>>
>>> sorry about latter one, thanks in advance
>>> joaquin
>>>
>>
>> I suggest you put a ''seam'' between your code and the
call the Kernel.
>>
>
> That sounds like a good idea.  You can also Kernel#` directly (instead of
> `foo` call Kernel.send(:`, "foo").  This allows you to stub out
Kernel#`.
>
> Scott
>
>
> _______________________________________________
> 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/20080913/9f3b1c20/attachment.html>

hi,
this did the trick:

  class Shell
    def self.sh command
      %{ command }
    end
  end

then I am able to:

it "should be mock alright" do
   Shell.should_receive(...).with(...)
end

is that correct so?

sorry aboout latter one (gotta do something about that hotkeys sendind my
mails all of a sudden)

thanks guys
joaquin

2008/9/13 Joaquin Rivera Padron <joahking at gmail.com>
> hi,
> this did the trick:
>
>   class Shell
>     def self.sh command
>       %{ command }
>     end
>   end
>
> then I am able to:
>
> it "should be mock alright" do
>
> end
>
> 2008/9/13 Scott Taylor <mailing_lists at railsnewbie.com>
>
>
>> On Sep 12, 2008, at 9:29 AM, Matt Wynne wrote:
>>
>>  On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
>>>
>>>  what is the best (or any) way of mocking the running of shell
commands?
>>>>
>>>> e.g.
>>>> code like the following:
>>>>
>>>> def method
>>>>  %{ ls }
>>>> end
>>>>
>>>> spec:
>>>>
>>>> it "should list the directory contents"
>>>>  shell = mock(Object) # %{} lives in Kernel module and its
sugar for `
>>>>  shell.should_receive(:`).with(:ls)
>>>> end
>>>>
>>>> sorry about latter one, thanks in advance
>>>> joaquin
>>>>
>>>
>>> I suggest you put a ''seam'' between your code and
the call the Kernel.
>>>
>>
>> That sounds like a good idea.  You can also Kernel#` directly (instead
of
>> `foo` call Kernel.send(:`, "foo").  This allows you to stub
out Kernel#`.
>>
>> Scott
>>
>>
>> _______________________________________________
>> 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/20080913/1a88abd0/attachment.html>

On 13 Sep 2008, at 13:42, Joaquin Rivera Padron wrote:
> hi,
> this did the trick:
>
>   class Shell
>     def self.sh command
>       %{ command }
>     end
>   end
>
> then I am able to:
>
> it "should be mock alright" do
>    Shell.should_receive(...).with(...)
> end
>
> is that correct so?
You''ve definitely got the idea, and that will work nicely for the  
examples you''ve given.

You might find that the code will reveal its intent a little better,  
and result in more readable specs if you think about exactly what  
role you want the shell to play for you in this particular instance,  
and create your shell-wrapping object with the specific methods that  
role needs to provide rather than a one-size-fits-all method as you  
have done here.

So, for example, if I want to be able to get and commit files from a  
source control repository, I can create a class like

class GitSourceControl
   def checkout(file)
     %x{ git checkout #{file} }
   end
end

This gives me a couple of advantages:

Firstly, my spec for the object which depends on the shell commands,  
looks like this:

it "should checkout the file" do

	filename = "blah"
	GitSourceControl.should_receive(:checkout).with(filename)
	# ... exercise the object under test...

Which is very readable and clear.

Secondly, if I ever want to change the type of source control I''m  
using, I can just write another class that implements the same  
interface - and swap out GitSourceControl for,  
SubversionSourceControl, say.

Does that make sense?

> sorry aboout latter one (gotta do something about that hotkeys  
> sendind my mails all of a sudden)
>
> thanks guys
> joaquin
>
> 2008/9/13 Joaquin Rivera Padron <joahking at gmail.com>
> hi,
> this did the trick:
>
>   class Shell
>     def self.sh command
>       %{ command }
>     end
>   end
>
> then I am able to:
>
> it "should be mock alright" do
>
> end
>
> 2008/9/13 Scott Taylor <mailing_lists at railsnewbie.com>
>
>
> On Sep 12, 2008, at 9:29 AM, Matt Wynne wrote:
>
> On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
>
> what is the best (or any) way of mocking the running of shell  
> commands?
>
> e.g.
> code like the following:
>
> def method
>  %{ ls }
> end
>
> spec:
>
> it "should list the directory contents"
>  shell = mock(Object) # %{} lives in Kernel module and its sugar for `
>  shell.should_receive(:`).with(:ls)
> end
>
> sorry about latter one, thanks in advance
> joaquin
>
> I suggest you put a ''seam'' between your code and the call
the Kernel.
>
> That sounds like a good idea.  You can also Kernel#` directly  
> (instead of `foo` call Kernel.send(:`, "foo").  This allows you
to
> stub out Kernel#`.
>
> Scott
>
>
> _______________________________________________
> 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
cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080913/91cf2e53/attachment.html>

cool, thanks

2008/9/13 Matt Wynne <matt at mattwynne.net>
> On 13 Sep 2008, at 13:42, Joaquin Rivera Padron wrote:
>
> hi,
> this did the trick:
>
>   class Shell
>     def self.sh command
>       %{ command }
>     end
>   end
>
> then I am able to:
>
> it "should be mock alright" do
>    Shell.should_receive(...).with(...)
> end
>
> is that correct so?
>
>
> You''ve definitely got the idea, and that will work nicely for the
examples
> you''ve given.
>
> You might find that the code will reveal its intent a little better, and
> result in more readable specs if you think about exactly what role you want
> the shell to play for you in this particular instance, and create your
> shell-wrapping object with the specific methods that role needs to provide
> rather than a one-size-fits-all method as you have done here.
>
> So, for example, if I want to be able to get and commit files from a source
> control repository, I can create a class like
>
> class GitSourceControl
>   def checkout(file)
>     %x{ git checkout #{file} }
>   end
> end
>
> This gives me a couple of advantages:
>
> Firstly, my spec for the object which depends on the shell commands, looks
> like this:
>
> it "should checkout the file" do
>
> filename = "blah"
> GitSourceControl.should_receive(:checkout).with(filename)
> # ... exercise the object under test...
>
> Which is very readable and clear.
>
> Secondly, if I ever want to change the type of source control I''m
using, I
> can just write another class that implements the same interface - and swap
> out GitSourceControl for, SubversionSourceControl, say.
>
> Does that make sense?
>
>
> sorry aboout latter one (gotta do something about that hotkeys sendind my
> mails all of a sudden)
>
> thanks guys
> joaquin
>
> 2008/9/13 Joaquin Rivera Padron <joahking at gmail.com>
>
>> hi,
>> this did the trick:
>>
>>   class Shell
>>     def self.sh command
>>       %{ command }
>>     end
>>   end
>>
>> then I am able to:
>>
>> it "should be mock alright" do
>>
>> end
>>
>> 2008/9/13 Scott Taylor <mailing_lists at railsnewbie.com>
>>
>>
>>> On Sep 12, 2008, at 9:29 AM, Matt Wynne wrote:
>>>
>>>  On 12 Sep 2008, at 14:12, Joaquin Rivera Padron wrote:
>>>>
>>>>  what is the best (or any) way of mocking the running of shell
commands?
>>>>>
>>>>> e.g.
>>>>> code like the following:
>>>>>
>>>>> def method
>>>>>  %{ ls }
>>>>> end
>>>>>
>>>>> spec:
>>>>>
>>>>> it "should list the directory contents"
>>>>>  shell = mock(Object) # %{} lives in Kernel module and its
sugar for `
>>>>>  shell.should_receive(:`).with(:ls)
>>>>> end
>>>>>
>>>>> sorry about latter one, thanks in advance
>>>>> joaquin
>>>>>
>>>>
>>>> I suggest you put a ''seam'' between your code
and the call the Kernel.
>>>>
>>>
>>> That sounds like a good idea.  You can also Kernel#` directly
(instead of
>>> `foo` call Kernel.send(:`, "foo").  This allows you to
stub out Kernel#`.
>>>
>>> Scott
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> cheers,
> Matt
> ----
> http://blog.mattwynne.net
> http://songkick.com
>
> In case you wondered: The opinions expressed in this email are my own and
> do not necessarily reflect the views of any former, current or future
> employers of mine.
>
>
>
>
> _______________________________________________
> 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/20080913/93e711bd/attachment.html>