When Your Mocks Burst into Flames

So yesterday Leah and I were working on SudokuScanner -- a cool little site that will, when it's released, allow you to upload images of Sudoku boards and get a solution. All of a sudden, our mocks and stubs went totally batshit. One minute she and I were happily writing some tests, making them pass, refactoring, checking in, etc... and then, we got a bunch of failures. OK, no problem -- we must have busted something with our latest change. The failure was a mock expectations error: UserMailer expected to receive a call to deliver_activation but did not receive it. So we went over to the failing spec and... There was no expectation on UserMailer anywhere in the spec.

That's bad.

Ran the spec by itself and it passes.

Yep - not so good.

Reverse the order that the specs run in (spec --reverse) and a different number of specs fail, but still with the same expectation failure. And of course these new specs all pass on their own. And have no reference to UserMailer anywhere in them. I searched the project and only one spec has one expectation on UserMailer.deliver_activation, but now I have 10 failing specs that are all failing because of that expectation.

So it appears the mocking framework isn't cleaning up after itself -- Yipes!

After a bunch of exploring/messing about I found myself in the spec_helper.rb file and I noticed something weird: The line 'config.mock_with :mocha' that should not be commented out is commented out. Which is weird because we're using Mocha as our mocking framework. So I uncomment it and run all the specs through rake. A billion errors all saying some variation of "method stub! does not exist" or "method should_receive does not exist."

Got it.

So it seems we are using RSpec's built in mocking framework on this project, but somebody started using Mocha too. Full disclosure: That somebody is probably me. I've been bouncing between a bunch of projects lately and some of them use Mocha and some use RSpec's mocking framework. I probably task switched over and started using Mocha without thinking about it and it just worked. I have Mocha installed as a gem on my machine and maybe that's enough, or maybe one of our plugins or gems requires it, but it's there apparently in the load path so everything was fine for awhile. Of course mocking frameworks do some pretty intense meta-craziness under the covers so it was bound to happen that using both would lead to one screwing up the other's functionality like, say, breaking Mocha's ability to clean up after itself. Which lead to our pile of nutty failures.

Luckily changing over to from Mocha to RSpec's mocking framework is not hard so we were able to purge the mocha syntax from the project and all was made well.

I could write a test that looks at all of my test files for Mocha syntax... Or is there a way to un-require Mocha explicitly so this doesn't happen again?

Comments

Anonymous said…
I have hit something like this, and I believe I determined that Rails internal use of Mocha had spilled over into my tests.
April 27, 2009 at 8:46 AM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more