On 14 June 2011 04:09, David Chelimsky <dchelim...@gmail.com> wrote:
> On Jun 13, 2011, at 9:44 PM, S Ahmed wrote:
>
> On Mon, Jun 13, 2011 at 9:37 PM, David Chelimsky <dchelim...@gmail.com>wrote:
>
> On Jun 13, 2011, at 8:29 PM, S Ahmed wrote:
>>
>> "How to mock when there seems to be a requirement for chained mocked
>> calls?"
>>
>> There is no such requirement unless you are imposing it by your own design
>> decisions.
>>
>> > I want to mock the following:
>> >
>> > MyModel.where(".....").last
>>
>> Why do you want to do this? Is this in a model spec? A controller spec?
>>
>> > I tried:
>> >
>> > MyModel.should_receive(:where).and_return(nil)
>> >
>> > but this of course doesn't match the expectation since the call to .last
>> was not mapped in the mock code.
>> >
>> > How can I do this?
>>
>> You _can_ stub (not mock) chains like this:
>>
>> MyModel.stub_chain(:where, :last).and_return(xxx)
>>
>> You can also set chained expectations like this (but I wouldn't recommend
>> it):
>>
>> ar_query = double('ar_query')
>> ar_query.should_receive(:last).and_return(nil)
>> MyModel.stub(:where).and_return(ar_query)
>>
>
> [I moved your post to the bottom]
>
> This is a method in my Model that I am writing a test for correct.
>
> There are allot of if/else clauses in the method, and i want to make sure
> certain things are called so I want to write expectations for it.
>
> This method will be hard to test because its not a good method. As its
already written you might be better of refactoring first to remove all the
if/else clauses. The most if/else clauses a method should have is 1!! A
session with the ruby refactoring book is in order :)
> Not sure why you don't recommend such a thing? (chained expectations)
>
>
> Because they are brittle.
>
> You can specify the externally observable behavior of a model without
> mocking its internals. This is _not_ the same as setting expectations on
> model methods called from controllers, in which case we're specifying how
> one component (the controller) talks to another component (the model). In a
> model spec, the model _is_ the component being specified. That all make
> sense?
>
> HTH,
> David
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
------------------------
Andrew Premdas
blog.andrew.premdas.org
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
