mocha developer - Sep 2007 - Parameter Matchers with optional params

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

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

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

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

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

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

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.

Personally I don''t tend to do this very much, but I don''t see
anything
particularly "wrong" with it. I think the RSpec mocking framework has
something built in for doing something similar for ActiveRecord objects.

On 25/09/2007, Andrew Vit <andrew at avit.ca>
wrote:
>
> 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.
> _______________________________________________
> 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