From jamesmead at reevoo.com  Mon Sep  3 07:29:54 2007
From: jamesmead at reevoo.com (James Mead)
Date: Mon, 3 Sep 2007 12:29:54 +0100
Subject: [mocha-developer] mocha tarballs don't uncompress cleanly
In-Reply-To: <20070801211739.GA5223@softwarelivre.org>
References: <20070725134425.GB26200@softwarelivre.org>
	<AD982887-64BD-41C0-AA91-0EF6117D58AB@reevoo.com>
	<20070725154130.GC5713@softwarelivre.org>
	<764E4F63-5F75-4420-A12F-1490BF269126@reevoo.com>
	<20070725172853.GA13035@softwarelivre.org>
	<525B9717-4C07-49BE-976B-56AAB8B1DFD4@reevoo.com>
	<20070727131256.GA5587@softwarelivre.org>
	<3446B288-9F34-4B87-975A-E005B4B5F4F2@reevoo.com>
	<20070801140604.GD21566@softwarelivre.org>
	<D7AE73B9-AF94-4F30-AA65-9A5C99DF7264@reevoo.com>
	<20070801211739.GA5223@softwarelivre.org>
Message-ID: <D2DF0423-2BCE-4816-AF43-26DCA542D9F3@reevoo.com>

Hi Antonio,

Did you ever get any further with this...?

I'm sorry - I've been busy at work, then ill, then on holiday.

I can only assume this means the Rake::GemPackageTask is to blame.  
I'm using version 0.7.3 of the Rake gem on a PPC Mac with OSX  
10.4.10. I wonder if it's worth trying to set up a dummy (virtually  
empty) project and trying to create a tarball using  
Rake::GemPackageTask and see if we can reproduce the problem...?

Cheers, James.


On 1 Aug 2007, at 22:17, Antonio Terceiro wrote:

> James Mead escreveu isso a?:
>> I think you're in luck - I'm pretty sure this is the one!
>
> Aha, just as I as I suspected: the tarball on rubyforge is different
> from the one you have.
>
> -----------------------------8<------------------------------------
> terceiro at sede:~/tmp$ ls -l
> total 36
> -rw------- 1 terceiro terceiro 33766 2007-08-01 17:06 mocha-0.5.3.tgz
> terceiro at sede:~/tmp$ wget -O mocha-rubyforge-0.5.3.tgz http:// 
> rubyforge.org/frs/download.php/23330/mocha-0.5.3.tgz
> --17:06:45--  http://rubyforge.org/frs/download.php/23330/ 
> mocha-0.5.3.tgz
>            => `mocha-rubyforge-0.5.3.tgz'
> Resolvendo rubyforge.org... 205.234.109.18
> Connecting to rubyforge.org|205.234.109.18|:80... conectado!
> HTTP requisi??o enviada, aguardando resposta... 302 Found
> Localiza??o: http://rubyforge.rubyuser.de/mocha/mocha-0.5.3.tgz  
> [seguinte]
> --17:06:46--  http://rubyforge.rubyuser.de/mocha/mocha-0.5.3.tgz
>            => `mocha-rubyforge-0.5.3.tgz'
> Resolvendo rubyforge.rubyuser.de... 80.237.222.133
> Connecting to rubyforge.rubyuser.de|80.237.222.133|:80... conectado!
> HTTP requisi??o enviada, aguardando resposta... 200 OK
> Tamanho: 33,768 (33K) [application/x-tgz]
>
> 100%[====================================>] 33,768        34.00K/s
>
> 17:06:48 (33.94 KB/s) - `mocha-rubyforge-0.5.3.tgz' saved  
> [33768/33768]
>
> terceiro at sede:~/tmp$ hexdump mocha-0.5.3.tgz > mocha-0.5.3.tgz.hex
> terceiro at sede:~/tmp$ hexdump mocha-rubyforge-0.5.3.tgz > mocha- 
> rubyforge-0.5.3.tgz.hex
> terceiro at sede:~/tmp$ diff -u mocha-0.5.3.tgz.hex mocha- 
> rubyforge-0.5.3.tgz.hex
> --- mocha-0.5.3.tgz.hex 2007-08-01 17:07:00.000000000 -0300
> +++ mocha-rubyforge-0.5.3.tgz.hex       2007-08-01  
> 17:07:08.000000000 -0300
> @@ -2108,5 +2108,5 @@
>  00083b0 ce9a 8e0e b77f fce9 0ef9 e709 6f21 15e6
>  00083c0 c4a8 5444 2a2d 6a59 9695 f2cf 3e59 67cb
>  00083d0 2cf9 e59f 7cb3 cf96 99f2 f3ff 03ff 2077
> -00083e0 13ff e800 0003
> -00083e6
> +00083e0 13ff e800 0003 0a0d
> +00083e8
> -----------------------------8<------------------------------------
>
> They are almost identical, but there is an extra newline byte pair  
> (0a0d
> = "\n\r") at the end of the file ... I checked and all the other files
> (*.zip and .gem) and they also have a 0a0d at their ends.
>
> I don't know what could be adding this extra newline ... :-(
>
> -- 
> Antonio Terceiro <terceiro at softwarelivre.org>
> http://people.softwarelivre.org/~terceiro/
> GnuPG ID: 0F9CB28F
>
>
>


From rsanheim at gmail.com  Wed Sep  5 15:32:38 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 5 Sep 2007 15:32:38 -0400
Subject: [mocha-developer] how to test timeouts? that #returns deprecation
	again...
Message-ID: <fc113d400709051232x53214fc5i5b10073ec970d11f@mail.gmail.com>

I'm writing quite a few specs lately that use Ruby's Timeout::timeout
functionality, making sure that timeout errors are properly handled
and everything flows right when some command line tools timeout.  I
like being able to use Mocha's #returns right now to force a method to
raise a TimeoutError, but I know that usage is going away at some
point.  I'd like to throw out the code and see if anyone has a better
way to test this with Mocha (or otherwise).

Here is some simplified code showing the example:

class FileSpace < ActiveRecord::Base
  def dsmc
   # remove command line wrapper object - this is basically a call
that _could_ stall out
  end

  def self.query_backup_timeout
    15.seconds
  end

  # query backup may hang things, so we have to wrap it in a timeout
  def query_backup_from_tsm
    Timeout::timeout(self.class.query_backup_timeout) do
      dsmc.parse_query_backup(dsmc.query_backup)
    end
  end
end

the corresponding spec:

describe "File Space" do
  it "should raise a time out error if query backup takes too long" do
    FileSpace.expects(:query_backup_timeout).returns(0.1) # make
timeout very short
    file_space = FileSpace.new
    # force the parse_query_backup method to sleep for 10 seconds,
therefore making the timeout happen
    file_space.dsmc.expects(:parse_query_backup).returns(lambda{ sleep(10) } )
    e = lambda { file_space.query_backup_from_tsm }.should.raise(Timeout::Error)
  end
end

Again, this is the simplest case -- in more complex examples I have
specs making sure that the timeout error is logged, and that the error
state gets saved to the database accordingly in the rescue clause.  In
other cases we used modules in our tests to override the real
implementation in the singleton class (by doing
dsmc.extend(TimeoutModule) for example), but thats a bit ugly and
tiresome.

Does anyone see a better way to do this?  I really just want to say "I
don't care what this method normally does, just pretend that in this
spec it takes n seconds long to complete to force a TimeoutError.

thanks,
Rob
-- 
http://robsanheim.com

From chris at chrislowis.co.uk  Wed Sep  5 17:04:16 2007
From: chris at chrislowis.co.uk (Chris Lowis)
Date: Wed, 5 Sep 2007 22:04:16 +0100
Subject: [mocha-developer] Mocking to spec a sort_by method
Message-ID: <6d92fa980709051404h2ba05383k5c8d4fdff61cbc94@mail.gmail.com>

Hello,

I have a question regarding the use of Mocha with rSpec to spec one of
my methods.

My spec contains the following

vehical1 = mock()
vehical2 = mock()
vehical1.stubs(:mph).returns(150)
vehical2.stubs(:mph).returns(250)
comparer.add_vehical([@vehical1, @vehical2])
comparer.sort_by(:mph)

The comparer is an object that has a basic "stack like" functionality,
add_vehical is the method to add objects to the stack.

My sort_by method in the comparer class looks like

def sort_by(symb)
    @vehicals.sort_by{|vehical| vehical[symb] }
end

where @vehicals is an instance variable array (the stack).

Running my spec gives the following error,

Mocha::ExpectationError in 'Comparer should be sortable on a specific symbol'
#<Mock:0x251b7c8>.[](:mph) - expected calls: 0, actual calls: 1

I assume sort_by is trying to call a [] method ? How do I stub this
method correctly using Mocha ?

Thank you for any help,

Chris









-- 
Chris Lowis
http://www.chrislowis.co.uk/

From zach.lists at gmail.com  Wed Sep  5 17:40:46 2007
From: zach.lists at gmail.com (Zach Moazeni)
Date: Wed, 5 Sep 2007 17:40:46 -0400
Subject: [mocha-developer] Mocking to spec a sort_by method
In-Reply-To: <6d92fa980709051404h2ba05383k5c8d4fdff61cbc94@mail.gmail.com>
References: <6d92fa980709051404h2ba05383k5c8d4fdff61cbc94@mail.gmail.com>
Message-ID: <D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>

I think you're meaning to do

vehical1.stubs(:[]).with(;mph).returns(150)
vehical2.stubs(:[]).with(;mph).returns(250)

Or in your prod code write vehicle.send(:mph) instead of vehical[symb]

Also in your test you should probably be doing comparer.add_vehical 
([vehical1, vehical2]) instead of @vehical1, @vehical2

Hope that helps.

-Zach

On Sep 5, 2007, at 5:04 PM, Chris Lowis wrote:

> Hello,
>
> I have a question regarding the use of Mocha with rSpec to spec one of
> my methods.
>
> My spec contains the following
>
> vehical1 = mock()
> vehical2 = mock()
> vehical1.stubs(:mph).returns(150)
> vehical2.stubs(:mph).returns(250)
> comparer.add_vehical([@vehical1, @vehical2])
> comparer.sort_by(:mph)
>
> The comparer is an object that has a basic "stack like" functionality,
> add_vehical is the method to add objects to the stack.
>
> My sort_by method in the comparer class looks like
>
> def sort_by(symb)
>     @vehicals.sort_by{|vehical| vehical[symb] }
> end
>
> where @vehicals is an instance variable array (the stack).
>
> Running my spec gives the following error,
>
> Mocha::ExpectationError in 'Comparer should be sortable on a  
> specific symbol'
> #<Mock:0x251b7c8>.[](:mph) - expected calls: 0, actual calls: 1
>
> I assume sort_by is trying to call a [] method ? How do I stub this
> method correctly using Mocha ?
>
> Thank you for any help,
>
> Chris
>
>
>
>
>
>
>
>
>
> -- 
> Chris Lowis
> http://www.chrislowis.co.uk/
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer


From duncanbeevers at gmail.com  Wed Sep  5 18:03:43 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Wed, 5 Sep 2007 15:03:43 -0700
Subject: [mocha-developer] how to test timeouts? that #returns
	deprecation again...
In-Reply-To: <fc113d400709051232x53214fc5i5b10073ec970d11f@mail.gmail.com>
References: <fc113d400709051232x53214fc5i5b10073ec970d11f@mail.gmail.com>
Message-ID: <6a2b4fd00709051503y44171c30s3ea10e764efeef07@mail.gmail.com>

Would it be acceptable to just have the potentially long-running
method raise the Timeout::Error itself and allow the error to
percolate up out of Timeout::timeout?

file_space.dsmc.expects(:query_backup).raises(Timeout::Error, 'took too long')

From zach.lists at gmail.com  Wed Sep  5 23:33:51 2007
From: zach.lists at gmail.com (Zach Moazeni)
Date: Wed, 5 Sep 2007 23:33:51 -0400
Subject: [mocha-developer] Mocking to spec a sort_by method
In-Reply-To: <D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>
References: <6d92fa980709051404h2ba05383k5c8d4fdff61cbc94@mail.gmail.com>
	<D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>
Message-ID: <7B155337-EF20-4365-B142-414D5DE0F366@gmail.com>

Doh typo,

that was vehical.send(symb) not vehical.send(:mph)

(Vehicle vs Vehical threw me off a bit)

-Zach

On Sep 5, 2007, at 5:40 PM, Zach Moazeni wrote:

> I think you're meaning to do
>
> vehical1.stubs(:[]).with(;mph).returns(150)
> vehical2.stubs(:[]).with(;mph).returns(250)
>
> Or in your prod code write vehicle.send(:mph) instead of vehical[symb]
>
> Also in your test you should probably be doing comparer.add_vehical 
> ([vehical1, vehical2]) instead of @vehical1, @vehical2
>
> Hope that helps.
>
> -Zach
>
> On Sep 5, 2007, at 5:04 PM, Chris Lowis wrote:
>
>> Hello,
>>
>> I have a question regarding the use of Mocha with rSpec to spec  
>> one of
>> my methods.
>>
>> My spec contains the following
>>
>> vehical1 = mock()
>> vehical2 = mock()
>> vehical1.stubs(:mph).returns(150)
>> vehical2.stubs(:mph).returns(250)
>> comparer.add_vehical([@vehical1, @vehical2])
>> comparer.sort_by(:mph)
>>
>> The comparer is an object that has a basic "stack like"  
>> functionality,
>> add_vehical is the method to add objects to the stack.
>>
>> My sort_by method in the comparer class looks like
>>
>> def sort_by(symb)
>>     @vehicals.sort_by{|vehical| vehical[symb] }
>> end
>>
>> where @vehicals is an instance variable array (the stack).
>>
>> Running my spec gives the following error,
>>
>> Mocha::ExpectationError in 'Comparer should be sortable on a  
>> specific symbol'
>> #<Mock:0x251b7c8>.[](:mph) - expected calls: 0, actual calls: 1
>>
>> I assume sort_by is trying to call a [] method ? How do I stub this
>> method correctly using Mocha ?
>>
>> Thank you for any help,
>>
>> Chris
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> Chris Lowis
>> http://www.chrislowis.co.uk/
>> _______________________________________________
>> mocha-developer mailing list
>> mocha-developer at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mocha-developer
>


From zach at elevatorup.com  Wed Sep  5 17:42:35 2007
From: zach at elevatorup.com (Zach Moazeni)
Date: Wed, 5 Sep 2007 17:42:35 -0400
Subject: [mocha-developer] Mocking to spec a sort_by method
In-Reply-To: <D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>
References: <6d92fa980709051404h2ba05383k5c8d4fdff61cbc94@mail.gmail.com>
	<D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>
Message-ID: <7CB92112-8A95-4D97-BD86-CE8450B270B5@elevatorup.com>

Doh typo,

that was vehical.send(symb) not vehical.send(:mph)

(Vehicle vs Vehical threw me off a bit)

-Zach

On Sep 5, 2007, at 5:40 PM, Zach Moazeni wrote:

> I think you're meaning to do
>
> vehical1.stubs(:[]).with(;mph).returns(150)
> vehical2.stubs(:[]).with(;mph).returns(250)
>
> Or in your prod code write vehicle.send(:mph) instead of vehical[symb]
>
> Also in your test you should probably be doing comparer.add_vehical 
> ([vehical1, vehical2]) instead of @vehical1, @vehical2
>
> Hope that helps.
>
> -Zach
>
> On Sep 5, 2007, at 5:04 PM, Chris Lowis wrote:
>
>> Hello,
>>
>> I have a question regarding the use of Mocha with rSpec to spec  
>> one of
>> my methods.
>>
>> My spec contains the following
>>
>> vehical1 = mock()
>> vehical2 = mock()
>> vehical1.stubs(:mph).returns(150)
>> vehical2.stubs(:mph).returns(250)
>> comparer.add_vehical([@vehical1, @vehical2])
>> comparer.sort_by(:mph)
>>
>> The comparer is an object that has a basic "stack like"  
>> functionality,
>> add_vehical is the method to add objects to the stack.
>>
>> My sort_by method in the comparer class looks like
>>
>> def sort_by(symb)
>>     @vehicals.sort_by{|vehical| vehical[symb] }
>> end
>>
>> where @vehicals is an instance variable array (the stack).
>>
>> Running my spec gives the following error,
>>
>> Mocha::ExpectationError in 'Comparer should be sortable on a  
>> specific symbol'
>> #<Mock:0x251b7c8>.[](:mph) - expected calls: 0, actual calls: 1
>>
>> I assume sort_by is trying to call a [] method ? How do I stub this
>> method correctly using Mocha ?
>>
>> Thank you for any help,
>>
>> Chris
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> Chris Lowis
>> http://www.chrislowis.co.uk/
>> _______________________________________________
>> mocha-developer mailing list
>> mocha-developer at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mocha-developer
>


From chris at chrislowis.co.uk  Thu Sep  6 12:13:44 2007
From: chris at chrislowis.co.uk (Chris Lowis)
Date: Thu, 6 Sep 2007 17:13:44 +0100
Subject: [mocha-developer] Mocking to spec a sort_by method
In-Reply-To: <D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>
References: <6d92fa980709051404h2ba05383k5c8d4fdff61cbc94@mail.gmail.com>
	<D78A9AA2-F704-4628-90CF-2B19C6AD6095@gmail.com>
Message-ID: <6d92fa980709060913y2895512fie417a2098482e2f2@mail.gmail.com>

> Or in your prod code write vehical.send(:mph) instead of > vehical[symb]

Zach,

Thank you ! That fixed the problem,

Chris

From lists-mocha at shopwatch.org  Thu Sep  6 14:14:54 2007
From: lists-mocha at shopwatch.org (Jay Levitt)
Date: Thu, 06 Sep 2007 14:14:54 -0400
Subject: [mocha-developer] Removing/overriding/unstubbing a stub?
Message-ID: <46E0439E.7000105@jay.fm>

We're using Mocha stubs to stub out a slow-performing network request in 
a Test::Unit class.  But naturally, we don't want to stub it out in the 
few tests that actually verify the functionality of that network request.

Is there a way to do the stub in "setup", but override it for the few 
tests that need the original functionality?

(I realize that in this case, the best solution is to refactor the class 
under test, and pull the network functionality into its own class.  But 
I can imagine there might be other scenarios where I'd want to do this too.)


Jay Levit


From duncanbeevers at gmail.com  Thu Sep  6 15:36:37 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Thu, 6 Sep 2007 12:36:37 -0700
Subject: [mocha-developer] Removing/overriding/unstubbing a stub?
In-Reply-To: <46E0439E.7000105@jay.fm>
References: <46E0439E.7000105@jay.fm>
Message-ID: <6a2b4fd00709061236j433cd3f6sf9dc38842336e5dc@mail.gmail.com>

A cheap way to do this would be to move the methods that actually test
the network functionality to their own instance of
Test::Unit::TestCase without the stubbing setup.

On 9/6/07, Jay Levitt <lists-mocha at shopwatch.org> wrote:
> We're using Mocha stubs to stub out a slow-performing network request in
> a Test::Unit class.  But naturally, we don't want to stub it out in the
> few tests that actually verify the functionality of that network request.
>
> Is there a way to do the stub in "setup", but override it for the few
> tests that need the original functionality?
>
> (I realize that in this case, the best solution is to refactor the class
> under test, and pull the network functionality into its own class.  But
> I can imagine there might be other scenarios where I'd want to do this too.)
>
>
> Jay Levit
>
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From rsanheim at gmail.com  Thu Sep  6 16:57:59 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Thu, 6 Sep 2007 16:57:59 -0400
Subject: [mocha-developer] any reason we can't use the concise stubs on
	Object
Message-ID: <fc113d400709061357p2628e24el62e629c2c29d8364@mail.gmail.com>

I like the concise version of stubs available on true mocks:

=> #<Mock:0x32f76d4>
>> foo.stubs(:one => 'hi', :two => 'again')
=> {:one=>"hi", :two=>"again"}

Why can't we do it on 'real' objects?

>> foo = Object.new
>> foo.stubs(:method1 => 'a', :method2 => 'b')
TypeError: #<Mocha::InstanceMethod:0x32f9100 @method={:foo=>"b",
:again=>"hi"}, @stubbee=#<Object:0x32fc364>> is not a symbol
        from /opt/local/lib/ruby/gems/1.8/gems/mocha-0.5.4/lib/mocha/mock.rb:148:in
`method_defined?'
        from /opt/local/lib/ruby/gems/1.8/gems/mocha-0.5.4/lib/mocha/mock.rb:148:in
`add_expectation'
        from /opt/local/lib/ruby/gems/1.8/gems/mocha-0.5.4/lib/mocha/mock.rb:88:in
`stubs'
        from /opt/local/lib/ruby/gems/1.8/gems/mocha-0.5.4/lib/mocha/auto_verify.rb:65:in
`stub'
        from /opt/local/lib/ruby/gems/1.8/gems/mocha-0.5.4/lib/mocha/object.rb:57:in
`stubs'
        from (irb):14

thanks,
Rob
-- 
http://robsanheim.com

From jamesmead44 at gmail.com  Tue Sep 11 10:10:31 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 11 Sep 2007 15:10:31 +0100
Subject: [mocha-developer] Fwd: [ mocha-Feature Requests-13763 ] add
	with_any_arguments method
In-Reply-To: <20070907214317.CC3DA5240CF3@rubyforge.org>
References: <20070907214317.CC3DA5240CF3@rubyforge.org>
Message-ID: <1db558f00709110710x79fcba93se8763b6907503fca@mail.gmail.com>

---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 7 Sep 2007 22:43
Subject: [ mocha-Feature Requests-13763 ] add with_any_arguments method
To: noreply at rubyforge.org

Feature Requests item #13763, was opened at 2007-09-07 17:43
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7480&aid=13763&group_id=1917

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Luke Melia (lukemelia)
Assigned to: Nobody (None)
Summary: add with_any_arguments method

Initial Comment:
We've found this useful when we don't care about the arguments passed to a
method. It would be great for it to find it's way into mocha.



module Mocha

  class Expectation

    def with_any_arguments()

      with(){ true }

    end

  end

end



Cheers from NYC,

Luke

----------------------------------------------------------------------

You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7480&aid=13763&group_id=1917


-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Tue Sep 11 10:11:28 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 11 Sep 2007 15:11:28 +0100
Subject: [mocha-developer] Fwd: [ mocha-Feature Requests-13763 ] add
	with_any_arguments method
In-Reply-To: <20070911140957.B01EC5240B68@rubyforge.org>
References: <20070911140957.B01EC5240B68@rubyforge.org>
Message-ID: <1db558f00709110711u312f788dw8a4921dbab900c5f@mail.gmail.com>

---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 11 Sep 2007 15:09
Subject: [ mocha-Feature Requests-13763 ] add with_any_arguments method
To: noreply at rubyforge.org

Feature Requests item #13763, was opened at 2007-09-07 21:43
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7480&aid=13763&group_id=1917

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Luke Melia (lukemelia)
Assigned to: Nobody (None)
Summary: add with_any_arguments method

Initial Comment:
We've found this useful when we don't care about the arguments passed to a
method. It would be great for it to find it's way into mocha.



module Mocha

  class Expectation

    def with_any_arguments()

      with(){ true }

    end

  end

end



Cheers from NYC,

Luke

----------------------------------------------------------------------

>Comment By: James Mead (jamesmead)
Date: 2007-09-11 14:09

Message:
Hi Luke,



Thanks for your interest in Mocha. I think the behaviour you are looking for
is the default behaviour for an expectation without a call to the
Expectation#with method, so all of the following tests should pass...



  def test_with_no_arguments

    weeble = mock('weeble')

    weeble.expects(:wobble)

    weeble.wobble

  end



  def test_with_one_argument

    weeble = mock('weeble')

    weeble.expects(:wobble)

    weeble.wobble(1)

  end



  def test_with_two_arguments

    weeble = mock('weeble')

    weeble.expects(:wobble)

    weeble.wobble(1, 2)

  end



  def test_with_three_arguments

    weeble = mock('weeble')

    weeble.expects(:wobble)

    weeble.wobble(1, 2, 3)

  end



Let me know if this is not what you meant...



Cheers, James.

----------------------------------------------------------------------

You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7480&aid=13763&group_id=1917


-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Tue Sep 11 10:31:26 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 11 Sep 2007 15:31:26 +0100
Subject: [mocha-developer] any reason we can't use the concise stubs on
	Object
In-Reply-To: <fc113d400709061357p2628e24el62e629c2c29d8364@mail.gmail.com>
References: <fc113d400709061357p2628e24el62e629c2c29d8364@mail.gmail.com>
Message-ID: <1db558f00709110731v38f6ac11g31915a2916808d63@mail.gmail.com>

No specific reason. I've been meaning to do it for a while, but not had the
time. I've added it to the todo list (revision 168).

-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From duncanbeevers at gmail.com  Tue Sep 11 16:21:51 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Tue, 11 Sep 2007 13:21:51 -0700
Subject: [mocha-developer] Expectations on portions of arguments called.
Message-ID: <6a2b4fd00709111321w59977016n3aa8005b559193dd@mail.gmail.com>

I'd like to create expectations on just portions of the arguments a
function takes.

For example, I want to verify that the a certain ActiveRecord
association extension adds an order clause to the find options hash.

Currently I simply check the entire argument structure, something like this

def test_referring_journals_should_order_by_citation_count
article = articles(:highly_cited_article)
Journal.expects(:find).with(
:all,
{
:order => 'citations_count DESC',
:joins => nil,
:select => nil,
:offset => nil,
:conditions => 'article_id = 1'
}
)
article.referring_journals
end

The example is fabricated, but what I'd like to do is something perhaps like:
def test_referring_journals_should_order_by_citation_count
article = articles(:highly_cited_article)
args = []
Journal.expects(:find, args)
article.referring_journals
assert_equal :all, args.shift
options = args.unshift
assert_equal 'citations_count DESC', options[:order]
end

Just kicking the idea around.

From jamesmead44 at gmail.com  Wed Sep 12 05:03:19 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 12 Sep 2007 10:03:19 +0100
Subject: [mocha-developer] Expectations on portions of arguments called.
In-Reply-To: <6a2b4fd00709111321w59977016n3aa8005b559193dd@mail.gmail.com>
References: <6a2b4fd00709111321w59977016n3aa8005b559193dd@mail.gmail.com>
Message-ID: <1db558f00709120203n204d7d71y46b044595d0b3f26@mail.gmail.com>

You should be able to do this with the has_entry parameter matcher (
http://mocha.rubyforge.org/classes/Mocha/ParameterMatchers.html#M000010)
something like this...

def test_referring_journals_should_order_by_citation_count
  article = articles(:highly_cited_article)
  Journal.expects(:find).with(:first, has_entry(:order, 'citations_count
DESC'))
  article.referring_journals
end

Let me know if I've misunderstood.

-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From duncanbeevers at gmail.com  Thu Sep 13 01:09:49 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Wed, 12 Sep 2007 22:09:49 -0700
Subject: [mocha-developer] Expectations on portions of arguments called.
In-Reply-To: <1db558f00709120203n204d7d71y46b044595d0b3f26@mail.gmail.com>
References: <6a2b4fd00709111321w59977016n3aa8005b559193dd@mail.gmail.com>
	<1db558f00709120203n204d7d71y46b044595d0b3f26@mail.gmail.com>
Message-ID: <6a2b4fd00709122209t35ff20dbhd37a82ba035a57fd@mail.gmail.com>

Wow, I hadn't seen those methods before.  Those do exactly what I need
in  99% of the cases I wished I had something like this.

Still though, there are times when having access to that arguments
array to do more programmatic checking, or deeper inspection of the
argument components would be nice.

Thanks for the quick response and excellent library.

On 9/12/07, James Mead <jamesmead44 at gmail.com> wrote:
> You should be able to do this with the has_entry parameter matcher (
> http://mocha.rubyforge.org/classes/Mocha/ParameterMatchers.html#M000010)
> something like this...
>
> def test_referring_journals_should_order_by_citation_count
>   article = articles(:highly_cited_article)
>   Journal.expects(:find).with(:first, has_entry(:order, 'citations_count
> DESC'))
>   article.referring_journals
> end
>
> Let me know if I've misunderstood.
>
> --
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jamesmead44 at gmail.com  Thu Sep 13 04:33:37 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 13 Sep 2007 09:33:37 +0100
Subject: [mocha-developer] Expectations on portions of arguments called.
In-Reply-To: <6a2b4fd00709122209t35ff20dbhd37a82ba035a57fd@mail.gmail.com>
References: <6a2b4fd00709111321w59977016n3aa8005b559193dd@mail.gmail.com>
	<1db558f00709120203n204d7d71y46b044595d0b3f26@mail.gmail.com>
	<6a2b4fd00709122209t35ff20dbhd37a82ba035a57fd@mail.gmail.com>
Message-ID: <1db558f00709130133td6ae626n3300faad71f5c43d@mail.gmail.com>

On 13/09/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> Still though, there are times when having access to that arguments
> array to do more programmatic checking, or deeper inspection of the
> argument components would be nice.

There's nothing to stop you writing your own custom parameter matcher
- in fact we often do this ourselves.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Thu Sep 13 07:32:23 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 13 Sep 2007 12:32:23 +0100
Subject: [mocha-developer] Removing/overriding/unstubbing a stub?
In-Reply-To: <6a2b4fd00709061236j433cd3f6sf9dc38842336e5dc@mail.gmail.com>
References: <46E0439E.7000105@jay.fm>
	<6a2b4fd00709061236j433cd3f6sf9dc38842336e5dc@mail.gmail.com>
Message-ID: <1db558f00709130432mc21c1bcrfdc0347eb4c7331@mail.gmail.com>

Personally I'm not a big fan of the setup method. I agree with Duncan
that two separate test cases is one way to go. Alternatively you could
move the stubbing out of the setup method and into invidual test
methods and only add it to the ones that need it - I think this has
the benefit of being clearer and more explicit, but it will depend a
bit on how many test methods need the stubbed method.

There has been an item on the todo list for a long time about being
able to "unstub" a method (I think it was first raised by Kevin
Clark), but not many people have asked for it and we (at Reevoo)
haven't needed it.

-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From duncanbeevers at gmail.com  Thu Sep 13 17:03:08 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Thu, 13 Sep 2007 14:03:08 -0700
Subject: [mocha-developer] Removing/overriding/unstubbing a stub?
In-Reply-To: <1db558f00709130432mc21c1bcrfdc0347eb4c7331@mail.gmail.com>
References: <46E0439E.7000105@jay.fm>
	<6a2b4fd00709061236j433cd3f6sf9dc38842336e5dc@mail.gmail.com>
	<1db558f00709130432mc21c1bcrfdc0347eb4c7331@mail.gmail.com>
Message-ID: <6a2b4fd00709131403n456f0449m388896c932a7f068@mail.gmail.com>

I think in most cases needing to unstub a method is an indication of
over-reaching setup methods and too-aggressive initial stubbing.

There are some instances however, where I'd like to unstub a method
before teardown.  For an example of such a case (good old Time.now)
and a potential approach, see this thread
http://rubyforge.org/pipermail/mocha-developer/2007-August/000409.html

On 9/13/07, James Mead <jamesmead44 at gmail.com> wrote:
> Personally I'm not a big fan of the setup method. I agree with Duncan
> that two separate test cases is one way to go. Alternatively you could
> move the stubbing out of the setup method and into invidual test
> methods and only add it to the ones that need it - I think this has
> the benefit of being clearer and more explicit, but it will depend a
> bit on how many test methods need the stubbed method.
>
> There has been an item on the todo list for a long time about being
> able to "unstub" a method (I think it was first raised by Kevin
> Clark), but not many people have asked for it and we (at Reevoo)
> haven't needed it.
>
> --
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From lists-mocha at shopwatch.org  Fri Sep 14 13:26:02 2007
From: lists-mocha at shopwatch.org (Jay Levitt)
Date: Fri, 14 Sep 2007 13:26:02 -0400
Subject: [mocha-developer] Removing/overriding/unstubbing a stub?
In-Reply-To: <1db558f00709130432mc21c1bcrfdc0347eb4c7331@mail.gmail.com>
References: <46E0439E.7000105@jay.fm>	<6a2b4fd00709061236j433cd3f6sf9dc38842336e5dc@mail.gmail.com>
	<1db558f00709130432mc21c1bcrfdc0347eb4c7331@mail.gmail.com>
Message-ID: <46EAC42A.4080606@shopwatch.org>

On 9/13/2007 7:32 AM, James Mead wrote:
> Personally I'm not a big fan of the setup method. I agree with Duncan
> that two separate test cases is one way to go. Alternatively you could
> move the stubbing out of the setup method and into invidual test
> methods and only add it to the ones that need it - I think this has
> the benefit of being clearer and more explicit, but it will depend a
> bit on how many test methods need the stubbed method.

Yeah, that's how we initially coded it, but calling the same stub 25 
times out of 28 tests felt pretty nasty!

But for me, refactoring the test (and probably the functionality) into 
two classes solves the problem so far.  I'll yell again if there's a 
case where it doesn't or where I wish it weren't needed.

Jay


From jamesmead44 at gmail.com  Fri Sep 21 11:13:13 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 21 Sep 2007 16:13:13 +0100
Subject: [mocha-developer] Stubbing yielding methods
Message-ID: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>

I've just been tying my brain in knots looking at bug #8687 (
http://rubyforge.org/tracker/index.php?func=detail&aid=8687&group_id=1917&atid=7477
).

I've been (1) trying to work out whether there is anything logically wrong
with Mocha's existing behaviour and (2) whether Mocha should support the
requested functionality.

It all centres around the use of the Expectation#yields method. I've put a
couple of examples together to try and help me think about it. The first one
(http://pastie.caboo.se/99412) is a simplified version of the example in the
bug report using a block and stubbing a method that yields to that block.

In the second example (http://pastie.caboo.se/99413) I tried to think about
how it would work if I converted the block to a method on an object. I
slightly ran out of steam on this one when I realised that in this case when
I realised Executor#execute wouldn't be called because the implementation of
Collaborator#yielding_method is stubbed.

This made me wonder if the Expectation#yields method should exist at all! In
particular, in the block example, it feels odd because you are going from
real code (ClassUnderTest) into mock code (mocked version of Collaborator)
and back into real code (the block itself). I wonder if this is really
sensible and/or useful.

Has anybody got any thoughts?

Thanks.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Fri Sep 21 12:20:19 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 21 Sep 2007 17:20:19 +0100
Subject: [mocha-developer] mock framework ethics question
In-Reply-To: <57c63afe0708220746m2bca12a8m8261530b9d267a73@mail.gmail.com>
References: <57c63afe0708220746m2bca12a8m8261530b9d267a73@mail.gmail.com>
Message-ID: <1db558f00709210920l386f3fd7qf23510316c0876b3@mail.gmail.com>

Hi David,

This is probably too late for you, but I'm inclined towards the third
"neither" option. This is because I prefer to stub the association method
itself which means I can use a standard mock for the model rather than an
rspec mock_model or whatever you call it.

Cheers, James.

On 22/08/2007, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> Hi James, Jim, and everyone else who's listening.
>
> I've been investigating an interesting bug related to mocks and rails
> AssociationProxies. See
> http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797
> for details.
>
> The crux is that if you do this (rspec mock syntax):
>
>   obj.should_receive(:msg).with(mock_of_a_model)
>
> and the implementation does this:
>
>   obj.msg(containing_model.association_proxy)
>
> the expectation fails. This is because the comparison that rspec mocks
> make is:
>
>   expected == actual
>
> which, in this case ends up being:
>
>   mock_of_a_model == association_proxy
>
> As it turns out, mocha and flexmock do this the same way, which means
> that this will fail in any of the three frameworks.
>
> So here's the mock-ethics question of the week:
>
> Should the comparison be changed to:
>
>   actual == expected
>
> or
>
>   actual == expected || expected == actual
>
> or ... neither?
>
> I have arguments for all three - I'd like to hear your thoughts.
>
> Cheers,
> David
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>



-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Fri Sep 21 12:21:30 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 21 Sep 2007 17:21:30 +0100
Subject: [mocha-developer] Removing/overriding/unstubbing a stub?
In-Reply-To: <46EAC42A.4080606@shopwatch.org>
References: <46E0439E.7000105@jay.fm>
	<6a2b4fd00709061236j433cd3f6sf9dc38842336e5dc@mail.gmail.com>
	<1db558f00709130432mc21c1bcrfdc0347eb4c7331@mail.gmail.com>
	<46EAC42A.4080606@shopwatch.org>
Message-ID: <1db558f00709210921t42c2e9cfh83af63d00a6e610f@mail.gmail.com>

Cool. Thanks.

On 14/09/2007, Jay Levitt <lists-mocha at shopwatch.org> wrote:
>
> On 9/13/2007 7:32 AM, James Mead wrote:
> > Personally I'm not a big fan of the setup method. I agree with Duncan
> > that two separate test cases is one way to go. Alternatively you could
> > move the stubbing out of the setup method and into invidual test
> > methods and only add it to the ones that need it - I think this has
> > the benefit of being clearer and more explicit, but it will depend a
> > bit on how many test methods need the stubbed method.
>
> Yeah, that's how we initially coded it, but calling the same stub 25
> times out of 28 tests felt pretty nasty!
>
> But for me, refactoring the test (and probably the functionality) into
> two classes solves the problem so far.  I'll yell again if there's a
> case where it doesn't or where I wish it weren't needed.
>
> Jay
>
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>



-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Fri Sep 21 12:49:41 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 21 Sep 2007 17:49:41 +0100
Subject: [mocha-developer] Debian package
Message-ID: <1db558f00709210949s6ec6f9b4rda984823022d4cbc@mail.gmail.com>

http://packages.debian.org/source/lenny/libmocha-ruby

-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From duncanbeevers at gmail.com  Fri Sep 21 16:30:28 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Fri, 21 Sep 2007 13:30:28 -0700
Subject: [mocha-developer] Stubbing yielding methods
In-Reply-To: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
References: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
Message-ID: <6a2b4fd00709211330p49acf6dcia55c9557497dc6aa@mail.gmail.com>

It's certainly necessary to test the code tucked away into these
blocks, but I feel like yielding is testing in the wrong direction.

Instead of yielding values or mocks into the block, perhaps we can
check metadata about the provided block (arity, required params) and
then test the functionality of the block explicitly.

class Test::Unit::TestCase
  def test_up_them_all
    upcasing_block = lambda { |e| e.upcase }

    list_of_words = [ 'socks', 'mittens', 'flashlight' ]
    list_of_words.expects(:map).with_block(upcasing_block)

    u = Upperizer.new
    u.up_them_all(list_of_words)

    assert_equal 'HONK', upcasing_block('honk')
  end
end


On 9/21/07, James Mead <jamesmead44 at gmail.com> wrote:
> I've just been tying my brain in knots looking at bug #8687 (
> http://rubyforge.org/tracker/index.php?func=detail&aid=8687&group_id=1917&atid=7477
> ).
>
> I've been (1) trying to work out whether there is anything logically wrong
> with Mocha's existing behaviour and (2) whether Mocha should support the
> requested functionality.
>
> It all centres around the use of the Expectation#yields method. I've put a
> couple of examples together to try and help me think about it. The first one
> (http://pastie.caboo.se/99412) is a simplified version of the example in the
> bug report using a block and stubbing a method that yields to that block.
>
> In the second example (http://pastie.caboo.se/99413) I tried to think about
> how it would work if I converted the block to a method on an object. I
> slightly ran out of steam on this one when I realised that in this case when
> I realised Executor#execute wouldn't be called because the implementation of
> Collaborator#yielding_method is stubbed.
>
> This made me wonder if the Expectation#yields method should exist at all! In
> particular, in the block example, it feels odd because you are going from
> real code (ClassUnderTest) into mock code (mocked version of Collaborator)
> and back into real code (the block itself). I wonder if this is really
> sensible and/or useful.
>
> Has anybody got any thoughts?
>
> Thanks.
> --
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jpywtora at calpoly.edu  Fri Sep 21 19:18:23 2007
From: jpywtora at calpoly.edu (John Pywtorak)
Date: Fri, 21 Sep 2007 16:18:23 -0700
Subject: [mocha-developer] Stubbing yielding methods
In-Reply-To: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
References: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
Message-ID: <46F4513F.7070703@calpoly.edu>

I would weigh in that something like yields is needed and possibly the 
suggested patches as well.  I do agree that it seems to work the wrong 
way.  I went and looked at how I had used yields and found what I think 
validates my assertion above.

Take for example: IO.open, IO.popen, etc.

puts IO.popen("ls", "r") { |pipe| pipe.read }

OK, so this example is contrived; However, I do think it points out some 
important things.  It is desirable to have expectations of both the call 
to popen, or the block, or both; However, rather than yield as a 
modifier to the methods expectations, separate the block's expectations, 
and return values out.  Basically rather than one statement combining 
the two, require two statements.

James Mead wrote:
> I've just been tying my brain in knots looking at bug #8687 (
> http://rubyforge.org/tracker/index.php?func=detail&aid=8687&group_id=1917&atid=7477
> ).
> 
> I've been (1) trying to work out whether there is anything logically wrong
> with Mocha's existing behaviour and (2) whether Mocha should support the
> requested functionality.
> 
> It all centres around the use of the Expectation#yields method. I've put a
> couple of examples together to try and help me think about it. The first one
> (http://pastie.caboo.se/99412) is a simplified version of the example in the
> bug report using a block and stubbing a method that yields to that block.
> 
> In the second example (http://pastie.caboo.se/99413) I tried to think about
> how it would work if I converted the block to a method on an object. I
> slightly ran out of steam on this one when I realised that in this case when
> I realised Executor#execute wouldn't be called because the implementation of
> Collaborator#yielding_method is stubbed.
> 
> This made me wonder if the Expectation#yields method should exist at all! In
> particular, in the block example, it feels odd because you are going from
> real code (ClassUnderTest) into mock code (mocked version of Collaborator)
> and back into real code (the block itself). I wonder if this is really
> sensible and/or useful.
> 
> Has anybody got any thoughts?
> 
> Thanks.

From andrew at avit.ca  Sun Sep 23 20:18:43 2007
From: andrew at avit.ca (Andrew Vit)
Date: Sun, 23 Sep 2007 17:18:43 -0700
Subject: [mocha-developer] Parameter Matchers with optional params
Message-ID: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>

Hi,

Are there any docs for combining parameter matchers, or some way to  
define optional parameters? I'm trying to match something like:

   .find( 42 )  ||  .find( 42, {:conditions=>nil,:includes=>nil} )

Or for that matter, 42 followed by nothing or anything... Halp? I've  
tried different nested combos with any_of/all_of/anything, but  
getting lost trying.

--Andrew Vit

From jamesmead44 at gmail.com  Mon Sep 24 06:11:49 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 24 Sep 2007 11:11:49 +0100
Subject: [mocha-developer] Parameter Matchers with optional params
In-Reply-To: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
References: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
Message-ID: <1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>

On 24/09/2007, Andrew Vit <andrew at avit.ca> wrote:
>
> Are there any docs for combining parameter matchers, or some way to
> define optional parameters? I'm trying to match something like:
>
>    .find( 42 )  ||  .find( 42, {:conditions=>nil,:includes=>nil} )
>
> Or for that matter, 42 followed by nothing or anything... Halp? I've
> tried different nested combos with any_of/all_of/anything, but
> getting lost trying.
>

Hi Andrew,

For the moment, I think you should be able to use the "parameter_block"
version of Expectation#with (
http://mocha.rubyforge.org/classes/Mocha/Expectation.html#M000024).

However, just to warn you, I'm intending to deprecate this mechanism in the
near future, but not until I can provide an alternative mechanism using
something similar to the ParameterMatcher style. I'll try to post here when
I get something committed.

Please let me know if you think the documentation could be improved.

Thanks.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From andrew at avit.ca  Mon Sep 24 21:22:24 2007
From: andrew at avit.ca (Andrew Vit)
Date: Mon, 24 Sep 2007 18:22:24 -0700
Subject: [mocha-developer] Parameter Matchers with optional params
In-Reply-To: <1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>
References: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
	<1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>
Message-ID: <C70F811F-F931-40E8-8F37-4FF390A7C05D@avit.ca>

On Sep 24, 2007, at 3:11 AM, James Mead wrote:

> For the moment, I think you should be able to use the  
> "parameter_block"
> version of Expectation#with (
> http://mocha.rubyforge.org/classes/Mocha/Expectation.html#M000024).
>
> Please let me know if you think the documentation could be improved.

That's great James. I rather like this way of matching parameters,  
much like Enumerable#detect... You're confident that the  
ParameterMatchers will be versatile enough to do away with the block?

The only point that wasn't fully clear in the docs is how it can work  
with multiple args... It's probably obvious to anyone who's worked  
with ruby blocks for a while, but I was getting the warning at first  
until I figured out how it works...

Here's a diff suggestion for your docs:


--- expectation.rb (saved version)
+++ (current document)
@@ -212,6 +212,17 @@
      #   object.expects(:expected_method).with() { |value| value % 4  
== 0 }
      #   object.expected_method(17)
      #   # => verify fails
+    #
+    # Multiple parameters can be received as an array.
+    # Note the use of a splat (asterisk) character on the
+    # block parameter in this usage:
+    #   object = mock()
+    #   object.expects(:expected_method).with() do |*args|
+    #     args[0] % 4 == 0 && args[1] == 29
+    #   end
+    #   object.expected_method( 2008, 29 )
+    #   => verify succeeds
+    #
      def with(*arguments, &parameter_block)
        @parameters, @parameter_block = arguments, parameter_block
        class << @parameters; def to_s; join(', '); end; end


Thanks!
--Andrew Vit


From zach.lists at gmail.com  Mon Sep 24 21:51:37 2007
From: zach.lists at gmail.com (Zach Moazeni)
Date: Mon, 24 Sep 2007 21:51:37 -0400
Subject: [mocha-developer] Parameter Matchers with optional params
In-Reply-To: <C70F811F-F931-40E8-8F37-4FF390A7C05D@avit.ca>
References: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
	<1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>
	<C70F811F-F931-40E8-8F37-4FF390A7C05D@avit.ca>
Message-ID: <381AB591-B425-4E66-8814-DCA6DC3C6BA4@gmail.com>

Actually,

I tend to use a more readable format when I do use the block format:

object = mock()
object.expects(:expected_method).with do | first_param, second_param |
   ...
end

Note - As I work with mocking more, I've noticed my dependence on the  
block matcher weaken considerably.

-Zach

On Sep 24, 2007, at 9:22 PM, Andrew Vit wrote:

> On Sep 24, 2007, at 3:11 AM, James Mead wrote:
>
>> For the moment, I think you should be able to use the
>> "parameter_block"
>> version of Expectation#with (
>> http://mocha.rubyforge.org/classes/Mocha/Expectation.html#M000024).
>>
>> Please let me know if you think the documentation could be improved.
>
> That's great James. I rather like this way of matching parameters,
> much like Enumerable#detect... You're confident that the
> ParameterMatchers will be versatile enough to do away with the block?
>
> The only point that wasn't fully clear in the docs is how it can work
> with multiple args... It's probably obvious to anyone who's worked
> with ruby blocks for a while, but I was getting the warning at first
> until I figured out how it works...
>
> Here's a diff suggestion for your docs:
>
>
> --- expectation.rb (saved version)
> +++ (current document)
> @@ -212,6 +212,17 @@
>       #   object.expects(:expected_method).with() { |value| value % 4
> == 0 }
>       #   object.expected_method(17)
>       #   # => verify fails
> +    #
> +    # Multiple parameters can be received as an array.
> +    # Note the use of a splat (asterisk) character on the
> +    # block parameter in this usage:
> +    #   object = mock()
> +    #   object.expects(:expected_method).with() do |*args|
> +    #     args[0] % 4 == 0 && args[1] == 29
> +    #   end
> +    #   object.expected_method( 2008, 29 )
> +    #   => verify succeeds
> +    #
>       def with(*arguments, &parameter_block)
>         @parameters, @parameter_block = arguments, parameter_block
>         class << @parameters; def to_s; join(', '); end; end
>
>
> Thanks!
> --Andrew Vit
>
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer


From jamesmead44 at gmail.com  Tue Sep 25 04:37:26 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 25 Sep 2007 09:37:26 +0100
Subject: [mocha-developer] Parameter Matchers with optional params
In-Reply-To: <381AB591-B425-4E66-8814-DCA6DC3C6BA4@gmail.com>
References: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
	<1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>
	<C70F811F-F931-40E8-8F37-4FF390A7C05D@avit.ca>
	<381AB591-B425-4E66-8814-DCA6DC3C6BA4@gmail.com>
Message-ID: <1db558f00709250137t36e88519o828f8785b4b55fa5@mail.gmail.com>

Andrew - Thanks for the feedback on the docs - I'll take a look.

Zach - I agree on both points.

-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Tue Sep 25 04:40:56 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 25 Sep 2007 09:40:56 +0100
Subject: [mocha-developer] Parameter Matchers with optional params
In-Reply-To: <1db558f00709250137t36e88519o828f8785b4b55fa5@mail.gmail.com>
References: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
	<1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>
	<C70F811F-F931-40E8-8F37-4FF390A7C05D@avit.ca>
	<381AB591-B425-4E66-8814-DCA6DC3C6BA4@gmail.com>
	<1db558f00709250137t36e88519o828f8785b4b55fa5@mail.gmail.com>
Message-ID: <1db558f00709250140k15d0ca45o89d0cdb88fa241b0@mail.gmail.com>

Andrew - Sorry. I also meant to say that I am confident that any replacement
for this style of matching will be versatile enough. I have two or three
ideas knocking around at the moment.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From andrew at avit.ca  Tue Sep 25 13:53:32 2007
From: andrew at avit.ca (Andrew Vit)
Date: Tue, 25 Sep 2007 10:53:32 -0700
Subject: [mocha-developer] Parameter Matchers with optional params
In-Reply-To: <1db558f00709250140k15d0ca45o89d0cdb88fa241b0@mail.gmail.com>
References: <BE20271E-0350-4BCF-AB15-74D23ACA63CA@avit.ca>
	<1db558f00709240311n3b35d980v3246563b16d5c637@mail.gmail.com>
	<C70F811F-F931-40E8-8F37-4FF390A7C05D@avit.ca>
	<381AB591-B425-4E66-8814-DCA6DC3C6BA4@gmail.com>
	<1db558f00709250137t36e88519o828f8785b4b55fa5@mail.gmail.com>
	<1db558f00709250140k15d0ca45o89d0cdb88fa241b0@mail.gmail.com>
Message-ID: <208AEAF5-67E1-44F9-A216-05DB0F0B09A2@avit.ca>

Sounds great... I'm all for syntactic sugar.

I'm pretty new to TDD and especially to mocking, so I'm sure I'm  
overreaching a bit for what I'm trying to do.

Do you guys ever use any helper methods to set up pre-fab mock  
objects for your test cases? Because that's what I'm trying to do for  
my ActiveRecord models, and it was tripping up depending an the exact  
parameters of the find method, hence my original question:

module Factory

   def self.method_missing( name, *args )
     # returns either a plain ActiveRecord Model.new with sensible,  
overrideable
     # model attributes, (not shown for clarity) or runs it through
     # self.proxy to make a mock if the method name has /^proxy_/
   end

   # give me a model that's "saved" to satisfy associations:

   def self.proxy( obj, obj_id )
     obj.stubs(:id).returns obj_id
     obj.stubs(:valid?).returns true
     obj.stubs(:new_record?).returns false
     obj.class.stubs(:find).with(){ |*args| args[0].class ==  
Fixnum }.returns obj
     obj
   end

end

I found I was using the above pattern a lot, to stub out saved AR  
objects to satisfy model associations, so I tried to abstract it into  
this helper. However, I sometimes call the find directly with just  
find(id), and the rest of the time it's called by ActiveRecord to  
validate the association, and that's why I needed to match & ignore  
any extra params.

--Andrew



On Sep 25, 2007, at 1:40 AM, James Mead wrote:

> Andrew - Sorry. I also meant to say that I am confident that any  
> replacement
> for this style of matching will be versatile enough. I have two or  
> three
> ideas knocking around at the moment.

From anaema_ml at yahoo.fr  Thu Sep 27 18:43:11 2007
From: anaema_ml at yahoo.fr (Christophe)
Date: Fri, 28 Sep 2007 00:43:11 +0200
Subject: [mocha-developer] Stubbing a module method
In-Reply-To: <1db558f00707300727s65483d58v273cc6e74514042a@mail.gmail.com>
References: <14cf210a0707300715i49a9f04dw4f716593e66e663b@mail.gmail.com>
	<1db558f00707300727s65483d58v273cc6e74514042a@mail.gmail.com>
Message-ID: <46FC31FF.5050605@yahoo.fr>

Hi, I'm trying to stub the login_required() method of the 
acts_as_authenticated plugin in an RoR integration test.
This method is defined in the AuthenticatedSystem module, in the 
lib/authenticated_system.rb

What happen is that the stub have no effect and the real method is still 
executed.

Here is the code. Any idea ?

Thank you



require "#{File.dirname(__FILE__)}/../test_helper"

class CheckStopsiteTest < ActionController::IntegrationTest
  fixtures :users
 
  def test_closed_site
    AuthenticatedSystem.stubs(:login_required).returns(true)
    get '/admin/maintenance/stop_site'
    assert_response :success
    get '/fr/site'
    assert_redirected_to :controller => 'site', :action => 'closed_site'
  end
 
end

From duncanbeevers at gmail.com  Thu Sep 27 19:10:11 2007
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Thu, 27 Sep 2007 16:10:11 -0700
Subject: [mocha-developer] Stubbing a module method
In-Reply-To: <46FC31FF.5050605@yahoo.fr>
References: <14cf210a0707300715i49a9f04dw4f716593e66e663b@mail.gmail.com>
	<1db558f00707300727s65483d58v273cc6e74514042a@mail.gmail.com>
	<46FC31FF.5050605@yahoo.fr>
Message-ID: <6a2b4fd00709271610s14d9d039nd7b097bae2ed3870@mail.gmail.com>

SiteController.any_instance.stubs(:login_required).returns(true)

perhaps?

On 9/27/07, Christophe <anaema_ml at yahoo.fr> wrote:
> Hi, I'm trying to stub the login_required() method of the
> acts_as_authenticated plugin in an RoR integration test.
> This method is defined in the AuthenticatedSystem module, in the
> lib/authenticated_system.rb
>
> What happen is that the stub have no effect and the real method is still
> executed.
>
> Here is the code. Any idea ?
>
> Thank you
>
>
>
> require "#{File.dirname(__FILE__)}/../test_helper"
>
> class CheckStopsiteTest < ActionController::IntegrationTest
>   fixtures :users
>
>   def test_closed_site
>     AuthenticatedSystem.stubs(:login_required).returns(true)
>     get '/admin/maintenance/stop_site'
>     assert_response :success
>     get '/fr/site'
>     assert_redirected_to :controller => 'site', :action => 'closed_site'
>   end
>
> end
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From anaema_ml at yahoo.fr  Thu Sep 27 19:20:14 2007
From: anaema_ml at yahoo.fr (Christophe)
Date: Fri, 28 Sep 2007 01:20:14 +0200
Subject: [mocha-developer] Stubbing a module method
In-Reply-To: <6a2b4fd00709271610s14d9d039nd7b097bae2ed3870@mail.gmail.com>
References: <14cf210a0707300715i49a9f04dw4f716593e66e663b@mail.gmail.com>	<1db558f00707300727s65483d58v273cc6e74514042a@mail.gmail.com>	<46FC31FF.5050605@yahoo.fr>
	<6a2b4fd00709271610s14d9d039nd7b097bae2ed3870@mail.gmail.com>
Message-ID: <46FC3AAE.7060908@yahoo.fr>

Unfortunately I already tried this too - And it doesn't work...


le 28/09/2007 01:10, Duncan Beevers nous a dit:
> SiteController.any_instance.stubs(:login_required).returns(true)
>
> perhaps?
>
> On 9/27/07, Christophe <anaema_ml at yahoo.fr> wrote:
>   
>> Hi, I'm trying to stub the login_required() method of the
>> acts_as_authenticated plugin in an RoR integration test.
>> This method is defined in the AuthenticatedSystem module, in the
>> lib/authenticated_system.rb
>>
>> What happen is that the stub have no effect and the real method is still
>> executed.
>>
>> Here is the code. Any idea ?
>>
>> Thank you
>>
>>
>>
>> require "#{File.dirname(__FILE__)}/../test_helper"
>>
>> class CheckStopsiteTest < ActionController::IntegrationTest
>>   fixtures :users
>>
>>   def test_closed_site
>>     AuthenticatedSystem.stubs(:login_required).returns(true)
>>     get '/admin/maintenance/stop_site'
>>     assert_response :success
>>     get '/fr/site'
>>     assert_redirected_to :controller => 'site', :action => 'closed_site'
>>   end
>>
>> end
>>