Cuc, Metal, and Stubs

[Nash]

Hi,

I've created a cucumber test to test a metal I've created that
connects to a third party.

I'm using rspec mocks to create a stub for the 3 party. It seems
that stubbing/mocking isn't extending all the way to the metal. It
calls the read object and not the stub.

Any idea of how I can make stubbing/mocking extend to the rails
metal?

I'm stubbing in a cuc step.

Thanks.

-Nash

[David Chelimsky]

Cucumber goes through rails integration tests, which go through rack, so stubbing something in a metal app should be no different than stubbing something on a model or controller. Please post the code in which you are using a stub so we can see what the disconnect might be.

Also, mocks (should_receive) won't be verified, so don't use those. Just use method stubs:

object.stub(:method_name) { return value }

Cheers,
David

[Nash]

Hi David,

It turns out my metal is running in development mode though it's
being invoked from cuc, which sets the env as cucumber.

I'm working on tracking down the issue now. Thanks for you help.

-Nash

[Nash]

Hi David,

It turned out I was doing a post using HTTParty instead of webrat
which was invoking the Metal in dev mode (set in my passenger).

But your response raised an interesting issue regarding the
verification of mocks.

In on of my steps, I have:

Given /^the subscription with id "([^\"]*)" has been "([^\"]*)"$/ do |
sub_id, state|
client = mock(Chargify)
response = Hashie::Mash.new(:state => state, :customer =>
{:reference => current_company.id})

client.should_receive(:subscription).with(sub_id).and_return(response)
Chargify::Client.stub!(:new).and_return(client)
end

Here's the related metal code:
def self.call(env)
...
@client = Chargify::Client.new('IuZH', 'xxx-test')
sub = @client.subscription(id.to_s)
...
end

When I run this code, it actually does verify the signature of the
subscription method. Here's how it complained:

Mock Chargify received :subscription with unexpected arguments
expected:
("666")
got: (666) (Spec::Mocks::MockExpectationError)

Which implies that mock verification is taking place, no?

Thanks.

-Nash
On Mar 18, 7:28 am, David Chelimsky <dchelim...@gmail.com> wrote:

[David Chelimsky]

Well, sort of :)

There are actually two different verification points, and I forgot about the first one when I said that. If you specify expected arguments, that is verified immediately when the message is received.

The part that is not verified is that the message was ever received at all. i.e. if you say this:

foo.should_receive(:bar).with(baz).and_return(something)

and foo never receives :bar at all, you won't be notified.

My recommendation would be to _not_ use should_receive at all.

HTH,
David

> Thanks.
>
>
> -Nash
> On Mar 18, 7:28 am, David Chelimsky <dchelim...@gmail.com> wrote:
>> On Mar 17, 2010, at 6:07 PM, Nash wrote:
>>
>>> Hi,
>>
>>> I've created a cucumber test to test a metal I've created that
>>> connects to a third party.
>>
>>> I'm using rspec mocks to create a stub for the 3 party. It seems
>>> that stubbing/mocking isn't extending all the way to the metal. It
>>> calls the read object and not the stub.
>>
>>> Any idea of how I can make stubbing/mocking extend to the rails
>>> metal?
>>
>>> I'm stubbing in a cuc step.
>>
>>> Thanks.
>>
>> Cucumber goes through rails integration tests, which go through rack, so stubbing something in a metal app should be no different than stubbing something on a model or controller. Please post the code in which you are using a stub so we can see what the disconnect might be.
>>
>> Also, mocks (should_receive) won't be verified, so don't use those. Just use method stubs:
>>
>> object.stub(:method_name) { return value }
>>
>> Cheers,
>> David
>

> --
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>