Using OpenStruct to Enhance Your Mocks

So I use RSpec's built in mocking framework for my mocking/stubbing and it works quite well. I sent up a mock like so:

mock_active_record_instance =
   mock("give it a name here, but probably a better one than this")

and put some expectations on it like so:

mock_active_record_instance.should_receive(:id).and_return(1)

but some calls to the mock I don't care about so I can stub them out like so:

mock_active_record_instance.stub!(:name).
   and_return("Arthur, King of the Britons")

If I don't need it to return anything I can leave off the and_return and it will return nil. But it's tedious to do that. Lately I tend to use OpenStructs as my mocks like so:

mock_active_record_instance = OpenStruct.new
mock_active_record_instance.should_receive(:id).and_return(1)

Now here's what's cool about that: My spec(test) will fail if the expectation of a call to id isn't met, but any other calls will be ignored (and nil returned). If I had made mock_active_record_instance a mock, like in the first example, I'd have to mock or stub out all the calls it's going to get and that is just painful. This way I can ignore the stuff I don't want to spec(test) painlessly.

You can also do fun stuff like so:

mock_active_record_instance = OpenStruct.new(:height => "5'10''",
          :weight => 260,
          :cars => ["hyundai", "saturn"])


So now mock_active_record_instance.cars will return an array with 2 stings. And height will return "5'10''" and weight will return 260. Maybe, in the future, a call to weight will return a smaller number -- I'm working on it.

Warning -- it may be that you have to do this because too many things are going on in the method you are specifying(testing). A better solution might be to figure out how to shorten up that method.

Jay Fields wrote about using OpenStructs in a series of blog posts about stubbing in rails which are totally worth reading.

Comments

Anonymous said…
Jake,

I've found that using OpenStruct as a stub can quickly become messy. Tests that use it can begin to rely on the fact that OpenStruct can maintain state. I've had much better success with the stub_everything method in mocha. It behaves the same as an OpenStruct, but it always returns nil.

Jay
March 24, 2007 at 6:16 PM
Dustin Tinney said…
I believe you can also say, object_mock = mock("some name" :null_object => true)
March 27, 2007 at 11:59 PM
Jake Scruggs said…
Good point about :null_object, that can come in handy. But when I use that, I have to stub/mock out things individually on seperate lines. When I use an OpenStuct I can define the things I want to be stubbed out with return values and the rest of the calls just return nil. One stop shopping.

I'm not exactly sure what Jay is talking about with the state problems, but unfortunately Mocha doesn't currently play nice with RSpec.
March 31, 2007 at 12:29 PM
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