I generally don't unit test the controller or the view layer, and just let my end-to-end acceptance tests ensure that everything is plugged together correctly. I will have them talk to an adapter within my domain, which is all well encapsulated and heavily unit tested. However if I'm dealing with a complex domain then I tend to separate out my domain layer from Rails, and treat my controllers as ports (from Alistair Cockburn's ports and adapters architecture) into and out of the web. The logic in Rails is simple enough that a computer could write it, so I don't really feel a high degree of risk there. My general response is two fold.įirst, if I'm just doing CRUD reading and writing, I don't really feel the need to have unit tests for the project, so long as I have end-to-end acceptance tests. CommentsĪ good number of people have asked me that question since I wrote the post. Super extra bonus points if you post links to open source projects that have a test suite that actually do these things well.
But still, the signature of a rails controller to call activerecord and render doesn't seem to lend itself to encapsulation and mocking.Īt this point I attempted to write what I thought was a change to the way controllers work using dependency injection and object composition, but I failed at it. So that means I would have an integration test on the controller. My gut at this point says I'm on an integration boundary between the user and my internal system. The functional test is testing internal state (assigns) and not messages passed by the controller.The actions taken by the controller are internal, not based on roles it should interact with.In our Rails controller and functional test, we can observe the following: He also intentionally doesn't touch the variable because it is internal to the system.
What can I mock? In Gregory Moeck's example, the ticket reservation object was passed in to the ticket machine interface (dependency injection) so we could easily mock the ticket reservation role and assert that the ticket machine interface interacted with it properly. While I really like his solution, something was nagging at me: how can I do this in Rails?įor example, here is the stock rails scaffold controller and functional test: class PostsController }Ĭlass PostsControllerTest < ActionController::TestCase He enforced the OO concepts of message passing and how mocks are better than stubs at testing very OO code.
One of the things I noticed in his article was that he was addressing some ruby classes and their interactions. I think the result of that post and the discussion that ensued was not that mocking and/or stubbing were bad practices, but that when they are applied inappropriately they can quickly deteriorate the tests and the design of an application.Īfter reading Gregory's article, I wanted to revisit the state of mocking in Rails applications. Readers of this blog may note that I had quite a rant against mocking almost a year ago and Gregory posted a response. Gregory Moeck's awesome post Stubbing is Not Enough got my brain back on the subject of mocking.
0 kommentar(er)
