Noel Rappin Writes Here

Here’s a little RSpec design question.

As I’ve probably mentioned in various spots, I don’t naturally take to the RSpec massively-mocked style of testing. However, I’m currently on a Rails project that is using that style – unit tests don’t touch the database, functional tests don’t touch the models. It seems to be working for them, they certainly seem to have stuck with it over the course of this rather complex application.

Anyway, today, my pair and I added a new before_filter to the layout of our application, where it gets called by every controller test in the system. This filter calls some user methods to put some dynamic user data on the screen.

Suddenly, we have failing tests all over the place, the vast majority of them related to mocks, mostly having to do with mocks or stubs that haven’t defined the method called in the filter and therefore thrown a mock expectation exception or, less frequently, a mock that does call these methods, but has an expectation that they will only be called once.

Wading through all these things is kind of daunting, and it’s not doing much to raise my general opinion of mock-heavy testing. That aside – I’m wondering how this is supposed to work. That is, I’m curious as to how a true RSpec expert would answer the following questions:

1. How would this issue – adding a new method call against an existing family of mocks – be handled in a perfectly designed and maintained RSpec test structure? What is the ideal here?

2. Given a system in progress that, while not bad, has had a lot of different people working on it in their own style, what’s the ideal way to proceed from here

Just wondering.