Should I make fun of my model in rail controller tests?

I find holes in my lighting because I made fun of my models in controller examples. When I remove the model method that the controller depends on, I don't get a crash.

Based on TDD in statically typed languages, I will always mock dependencies with the test object, which gets into the database to increase speed. I would still get crashes in the above example, since my layouts subclassed the original object. I am looking for best practices in a dynamic language.

Thanks.

UPDATE:

Having received many conflicting opinions on this subject, it seems that it comes down to what kind of philosophy you are buying.

The Rspec community seems to embrace highly dependent dependencies to achieve isolation of the test object. Acceptance tests (traditionally known as integration tests;) are used to ensure that your objects work with their dependencies at runtime.

The shoulda / Test :: Unit community does not seem to intervene as much as possible. This allows you to verify that your test object is working with its dependencies.

In this video, it is clearly visible: http://vimeo.com/3296561

+4
source share
3 answers

Yes, in the examples of your controller, mock your models. In the model examples, check your models.

+2
source

If you are using Mocha, this should do the following.

Mocha::Configuration.prevent(:stubbing_non_existent_method) 
+2
source

When writing unit tests, the whole goal should be to test this device only. Consider the model as a whole and cover it separately. Changing the model should not directly affect the scope of the unit test controller.

0
source

All Articles