I actually gave up trying to convert to rSpec for my controller code because the information I normally got through a failed test was chomped. Example: assert_response. Rspec: response.should be_success => response.success
? which gives me True or False and no more information while assert_response gives me “Response was <400> when you expected <200>”. Of course, I could just use the normal assert functions, but that’s not all
I’ve also found that a very important part of functional testing is making sure that my views compile. As rSpec for Rails wants to disconnect the controller code from the view (in general MVC architectures the right thing to do), I no longer know if my views even compile, much less function. Of course I put together (right now) selenium tests to make sure my views actually function, but when it comes to Rails refactoring, it’s a very good idea to know if your views compile or not, and rSpec by default keeps that information away from you. As the whole point of a controller action is to process data in order to render out a response, I’m not a fan of the rspec’s view separation.
Of course, I may just be nit-picking, as all of this has a work-around to it (#include_views, I think it’s called, and using regular assertion functions).
Otherwise rSpec is a great tool that really should be a requirement in any project.
rSpec’s web site has some pretty thorough documentation, though I’ve also found a few blog posts that help out with the Rails side:
(more about models, but a decent reference) http://lukeredpath.co.uk/2006/8/29/developing-a-rails-model-using-bdd-and-rspec-part-1
Hope that helps.