Controller tests bleeding to models?

I am writing some tests with RSpec (tests and not specs, the code was untested until now) and have stumbled upon an uncertainty...

I want to know whether a controller is calling the model's methods properly and I am divided between the possibilities:

• test the controller with stubbing the model method (I won't know if the model method actually exists or accepts the arguments given)
• leave the model method unstubbed and risk having my controller tests bleed into model test territory (and also make them slow caus开发者_Go百科e of DB access and costly methods)
• write multiple controller tests, each of them leaving unstubbed one model method (still slow as hell but at least it's verbose)

Is there a correct answer on this?

You could stub the model method if you want, but in general you shouldn't check in controller test that particular method of a model was called you should check controller's response content. Don't forget about black box metaphor.

I suggest you test your controllers without stubbing your models. Do not care about the speed of the tests when it hits the database. I assume you want to have the database also tested, and having a correct program is more important than the speed of your tests, isn't it?

Consider the functional tests as another layer around your unit tests, not as something that is isolated from your models. Your unit tests (models) ensure that some model methods work as expected, and then your controller tests ensure that the controller is able to use these methods, and they work as the controller expects.

As iafonov said, do not focus on the model's methods in your controller tests. Assume that if your controller is able to give you the correct response, then your model apparently works as expected.

Of course, some people have different point of view. I do not claim that my suggestion is the best. It just works for me, and I consider it being right. A lot of people suggest that you should test your controller in isolation from models, but how do you ensure then that there is no discrepancy between your stubs and your real implementation?

I'm pretty late to the party. But agree strongly with solnic and disagree with Arsen7.

Think about it:

• If you are using vanilla active record methods, e.g. MyModel.find_by_id(123) you can safely stub that because AR is already well tested, no need to his the database for those.

• If you are calling a custom method you defined on the model, e.g. MyModel.foo(param1, param2) then you should still mock/stub it because you should have a test for it in your MyModel spec.

The only downside to stubbing model methods is that sometimes if you change the interface for a method your controller will be ignorant of that change and the test will still pass. Typically either integration or manual tests will uncover the problem. If you are working on a large project speed quickly becomes an issue and avoiding the perf hit from interacting with the database is more than worth an occasional head scratch imho.

With good model/unit tests it's recommended to stub models in controller specs (and it is obviously recommended to have good model/unit specs heh). Full stack should be covered by requests/acceptance specs anyway. I like to treat controller specs as 'unit specs' for controllers. With skinny controllers stubbing model in specs should be easy and should not touch any implementation details.