I’m still a testing newbie so my opinions might change in the future but for right now I am “hold the onions” sort of guy (as referred to in the second part of Mike’s article). In an ideal world your unit testing will be ensuring that everything the controller expects your models to do are being done. But in the real word you might miss something in your unit testing on your models. So your controller testing using real models may pick up that mistake allowing you to correct your unit testing.

For me the more I move away from my actual code the less I am testing of my actual code. Mocks can be useful but most of the time for me real code is where it is at.

I can highly recommend Jay Fields’ approach to this: http://blog.jayfields.com/2007/09/rails-how-we-test.html

I’ve been testing like this for a few months now and wouldn’t go back. I also like the use of a Factory instead of fixtures as mentioned in the article.

@Eric

Understandable, and coming from a background of straight JUnit with no mocking what-so-ever, I’m almost in the same boat. On large projects however, mocking/stubbing schemes can be justified… as suites can start to creep up to 30+ minutes a run, which is much too slow IMHO. Specifically for simple controllers, authentication, etc… mocking/stubbing makes a lot of sense to me.

@Jamie

I primarily use RSpec, and haven’t found the need to do the unit / functional abstraction for unit tests. I’ve used Presenters, Validateable… etc… and this is the probably the one thing that I haven’t picked up from Jay yet :) Would love to hear a bit more about your likes and dislikes of using this approach. On a side note, I’ve been using a Factory for a while, and definitely prefer it as well :)

@Dylan Do you really need to run your full tests all the time. The default rake files with rails have the ability to run recent and uncommitted tests. Also you can run just the model or controller you are hacking on.

Then occasionally throughout the day run the full test in the background (while you are hacking or are at lunch) to verify nothing affected an unrelated system.

But then again even my largest projects only take about 5 minutes to do the full testings so perhaps I would like mocking if I ran into the time thing more. I guess I am not testing enough. :)

@Eric Good questions ! No, definitely don’t need to be running the entire suite all the time, and will usually use autotest, or, just spec on the code I’m dealing with. Aside from the annoyance of it taking a long time, CruiseControl can get hammered when tons of commits are coming through, and spawning half-hour suite runs. The whole process is still pretty discretionary… and, color me “hold the onions” as well, but I’d rather be safe than sorry :)