Sometimes you find an elegant solution for a problem that doesn't exist. So, what do you do then? In my case, I just forgot about it for a while.
About five or six years ago, I was invited to a testing summit. There were plenty of testing gurus in attendance: Cem Kaner, Brian Marick, Bret Pettichord, and James Bach were all there. I was there along with a few other developers to talk about TDD, refactoring and some of the more agile development techniques. We all sat together and worked on tests and testing approaches for an application that Pragmatic Dave Thomas had written. It was a blog publication system written in Ruby.
We sat, coded, and discussed things into the wee hours of the night. And, like, most geeks, we didn't really go outside much. When we had breaks, we huddled around our computers and read the web to see if the world had changed outside.
During one of these breaks, I started playing with an idea that was inspired by the method_missing method in Ruby.
What if we had a class like this:
class Pebble
def method_missing(meth, *args)
puts meth
return self
end
end
We could find some arbitrary method in an application that we don't understand, and just drop a Pebble into it.
controller = BasicController.new
controller.accept_renderer(Pebble.new)
Then we'd see a trace of all of the calls to that object, and we'd see traces to calls to all of the returned objects as well. It would be kind of like dropping a pebble into a cave. You drop it, and listen to it on the way down. As you listen you can tell how deep the cave is, and get a sense of its layout. Hokey? Yes, but give us a break. It was late.
We sat and played with this idea a bit. I forget who the other developers were but Jeremy Stell-Smith was there. The code, unfortunately, is long gone. And, it's a shame. We ran into some interesting cases when the pebbles bottomed out at operator calls and primitives in Ruby.
We had pebbles generate other pebbles, and we built up a list of calls with appropriate indentation. And, although we didn't have time to code it, we thought about bringing up a GUI with the source and allowing people to type in the return values of various calls as a pebble dropped.
Unfortunately, we didn't see much practical use to the idea but it still seemed kind of neat. It's just a shame that it was a solution to a problem that didn't exist.

Comments (4)
What an awesome idea. Thanks for sharing it.
Posted by Ryan Z. | January 5, 2008 3:20 PM
Hi,
quite interesting indeed. It reminds me of minimock, a python module by Ian Bicking which leverages python's doctest to create very simple test code where mocking is needed. Check it out at:
http://pypi.python.org/pypi/MiniMock
(Original article at:
http://blog.ianbicking.org/minimock.html )
Maybe Pepples could be worked into a similar facility (I've seen doctests for Ruby somewhere as well).
Best regards.
Posted by Niklas | January 5, 2008 7:16 PM
Funny, one of my colleagues (Nate Jackson) just coded that exact same class last month (sans puts) but called it Sponge, for use in testing as an easy way to pass an object into a method when you don't want to bother with its calls or calls to its children. It's such a great little construct.
Posted by Dave Hoover | January 5, 2008 11:57 PM
And another instance.
We used this pattern with jMock to figure out what callbacks third party libraries make. In particular, when trying to work out what a Java SSH framework did. jMock will explode with some helpful information if you call an object unexpectedly.
Posted by Steve Freeman | January 6, 2008 1:01 PM