Going back on Mocking & Stubbing with RR (kind of)

Almost 2 months ago I wrote an article called A case against Mocking and Stubbing. In it I outlined why I think mocking & stubbing is a bad idea. I still maintain some of those beliefs but since I’ve been playing with the mocking framework RR I have changed my tune some.

RR allows for a much cleaner and faster way to write mocks and stubs. There is a whole lot more to the framework that I won’t get into here. What I will say is that I have started to use RR in my functional tests. And not just to mock outside resources.

In my cited post I described my development process: start at a very high abstraction level (user stories) work my way down the stack until you get to the unit tests, then go back up making each level pass. This creates a high level of integration into the app and makes certain that if you change something in a lower level the change is felt at the higher levels.

So, my argument previously was that if you mock your models and stub out their methods in the functional tests then you lose that level of integration between your models and controllers. If you changed something in your model your functional tests would still pass because the behavior has been stubbed out.

There should be no reason to change the behavior of Active Record. Monkey Patching is generally a bad idea. So if we can assume that we will *never* change the behavior of Active Record then there is no reason why we cannot stub out that behavior.

For the sake of my fingers I have pretty much limited my stubbing to any AR methods that hits the database. AR#save, AR.find are of course the two big ones. I think I’m settling upon this testing scheme for the time being.