Comments on: On Rails Testing

By: John Quarto-vonTivadar

John Quarto-vonTivadar — Wed, 04 Nov 2009 01:49:57 +0000

Yehuda, are you still working on a new Rails 3 book via Manning? The book they’re selling with that title is a Merb book and there haven’t been any pre-release updates in months. Just wondering if you’ve dropped the idea of completing the Rails 3 book.

By: Gabe Hollombe

Gabe Hollombe — Tue, 23 Jun 2009 03:06:03 +0000

Thanks for the replies, Francis and Yehuda. Francis, I’ll give your talk a view when I’ve got a spare hour. And yeah, Yehuda, I also like your rule of thumb; thanks for sharing that.

By: schwabsauce

schwabsauce — Mon, 22 Jun 2009 20:00:52 +0000

Isn’t rr the answer to this dilemma, the need for both a simple, atomic test of behavior (mock) and also an integrated black box test (no mock)? Doesn’t the proxying feature have some bearing on this?

By: Sinclair

Sinclair — Mon, 22 Jun 2009 16:15:21 +0000

Be wary before knocking the mocking. When such things SAS, web services, legacy systems, payment gateways exist … it is possible to see a means of designing and testing interactions across such boundaries. And the reason why mocking and stubbing are considered useful solutions to such recurring problems.

Don’t knock the mock!

By: Francis Hwang

Francis Hwang — Mon, 22 Jun 2009 12:19:35 +0000

Arg, “Don’t mock anything you own”, even.

By: Francis Hwang

Francis Hwang — Mon, 22 Jun 2009 03:18:46 +0000

Gabe: Well, if you’ve got a free hour, you could watch the “Testing Heresies” talk I gave at the last RubyConf. A lot of it is devoted to the subject of mocking: http://rubyconf2008.confreaks.com/testing-heresies.html

In a nutshell, I’d say that I think it is system integrity that matters in your application, not how layers interact. I find that mocking is a way to lock down layer interaction, but that doesn’t do you any good if the overall system doesn’t work, and in fact is a detriment when you have to do serious refactoring and have to spend extra time dragging your mocks along with you.

Yehuda: “Don’t mock anything you don’t own” is a great rule of thumb, I’d say.

By: George Feil

George Feil — Sun, 21 Jun 2009 20:52:42 +0000

I’m glad I’m not the only one struggling with mocks. I find them frustrating to use sometimes. Mocha, for example, doesn’t handle stubbing and mocking class methods very well, which causes me to mock / stub much deeper than I expect to.

By: wycats

wycats — Sun, 21 Jun 2009 17:37:05 +0000

Mocking out a call to a REST API is a pretty good use-case for mocks. My general rule is “Don’t mock anything you own” and more strictly “Don’t mock anything happening inside your own process”. There are people who use mocks to good effect, but they’re an extremely sharp tool and my experience is that the people who use them well are very skilled programmers with an extremely honed testing philosophy.

By: Gabe Hollombe

Gabe Hollombe — Sun, 21 Jun 2009 09:08:16 +0000

@Francis, I’m just learning about mocks and stubs and, because I value your opinion, I’m wondering if you can provide a link or two about why you’re an anti-mocking zealot?

I just used Mocha to mock out a call to a 3rd party REST API call for my tests. Surely this is an ok use case for mocks, right? So where do they go wrong?

By: Ben

Ben — Sun, 21 Jun 2009 02:49:17 +0000

I’ve realized recently that although mocks have their place (in unit tests), they need to be complemented by higher levels tests to gain real confidence (especially during refactoring). It also helps if the mocking framework allows a way to do checks on mocks (so they can’t have an entirely different interface than the object they are supposed to be replacing). Mocha sort of has this with it’s #responds_like method, but it’s not a full solution. I’m not sure what capabilities other mocking libraries offer.