Calling expects on Rails 3.0 mailer causes method to return nil

[crystalneth]

UserMailer.comment_notification => [something]
UserMailer.expects(:comment_notification)
UserMailer.comment_notification => nil

[floehopper]

This is the intended behaviour of Mocha. When you call UserMailer.expects(:comment_notification), the UserMailer.comment_notification method is replaced by a stub method for the rest of the test. The default is for this stub to return nil, unless you use Mocha::Expectation#returns, or Mocha::Expectation#raises.

It would be useful to understand what were you expecting to happen so that I can try and improve the documentation if it is lacking. Were you expecting the method to still execute the original UserMailer.comment_notification method and still return the same return value as if you had not called UserMailer.expects?

Thanks, James.

[crystalneth]

I didn't know this, but that explains it.

I'm trying to add tests for how many emails are sent and who they are sent to, so I was using UserMailer.expects(:comment_notification).with(...).once

The mailer stuff calls UserMailer.comment_notification.deliver, which of course throws a null pointer in this case. I guess it doesn't make sense to me that .expects also stubs the method, because that could throw wrenches up an application in any number of ways, and prevents you from doing a lot of tests.

Can I have it just call through to the original method? This would be a lot less intrusive.

I ended up defining helper methods and tracking through those.

[crystalneth]

Even that though is not ideal.

I want to BOTH count the method calls AND run the mailer code. Right now mail templates are not being tested in this case.

[floehopper]

Thanks for clarifying what you were expecting to happen. I will try and improve the documentation for the expects method to make it clearer what will happen.

In general the idea of Mock Objects is to isolate the object (or objects) under test from its (or their) collaborators. In almost all mocking frameworks you will find that setting an expectation also creates a stub implementation. The idea is that you have total control over this stub implementation and can provide canned return values specified in the test.

When you say "mail templates are not being tested", are you saying that you want them to be tested, but the fact that Mocha is intercepting the call to UserMailer.comment_notification means that they are not being tested?

If so, I'd be inclined to split the test into two types of test - one which uses Mocha to set up expectations for the calls to UserMailer and another which makes real calls to UserMailer and checks the templates are rendered without an error.

If you are set on the idea of counting the number of calls, but still calling the real implementation, I believe Brian Takita's RR library will do what you want (see the section headed mock.proxy).

Alternatively, you could use ActionMailer with its delivery_method set to :test: and inspect ActionMailer.deliveries.

I hope that helps.

[floehopper]

I've created this Lighthouse ticket to deal with improving the documentation. Please close this Issue if you are satisfied with the response.

Regards, James.

[crystalneth]

Thanks James. I can see how isolating would be good, however I generally prefer broader tests to catch any template errors.

[floehopper]

Since that's a subjective issue of style, I think we're going to have to agree to differ. But I think the only change I'm going to make to Mocha is to improve the documentation as described above. So for the moment, I'm going to close this issue.

[crystalneth]

Sure, no problem. Seems like an expects that also calls through would be a nice new feature, particularly in a case like this, where the return value from the method you want to count is used by third party code.

[floehopper]

Cool. There's already a Lighthouse ticket for the feature you describe in case you want to voice your support, further explain the motivation for the feature, etc.