Comments on Brian Cardarella's Blog: A case against Mocking and Stubbing

Put your test-DB on a ramdisk or on a SSD and you'...

2008-12-18T05:15:00.000-05:00

Put your test-DB on a ramdisk or on a SSD and you're halfway there.

I think the crux of your argument is the assertion...

2008-12-11T19:25:00.000-05:00

I think the crux of your argument is the assertion that "functional tests should rely upon the models being written properly." I don't see the support for that assertion.

I also think that you're not accounting for integration tests, which will indeed fail if the model is not correct.

"What if I change something on my model down the l...

2008-12-11T16:17:00.000-05:00

"What if I change something on my model down the line, my unit test will fail, I fix that. But my functional tests still pass because I m&sed that functionality."

A technique that can help alleviate that problem is to use a stub/mock that will check the method you are stubbing/mocking actually exists with the correct arity on your model. Brian Takita's rr framework supports this technique by prepending your stub/mock with strong. This provides the benefit of not being concerned if the implementation of model#whatever is correct, while also providing you with errors if model#whatever is removed or it's signature changes.

Thanks for all of the responses. This seems to hav...

2008-12-11T15:05:00.000-05:00

Thanks for all of the responses. This seems to have really gotten under the skin of some Rspec people. Not my intention but still interesting. I still maintain my opinion that within an integrated testing approach that mocking/stubbing is going to cause major issues. One valid reason to use mocking/stubbing in this context would be when accessing resources outside of your project. (Geocoded data for example)

I guess I should have made the database stuff a separate post because in all honesty I am more interested in that.

topfunky: thanks for the update on using SQLite for an in-memory database. True, no code is faster than no code. But, as I stated RAM is faster than disk IO. I wonder if MySQL could be adapted to write to memory instead of disk. SQLite is slow in general, but is a good place to start for an app considering how easy it is to setup.

Take off your rails colored glasses...There are va...

2008-12-11T13:38:00.000-05:00

Take off your rails colored glasses...

There are valid critiques of mocking, but you aren't really making those.

Your basic argument is that you can't test integration of components when you are just playing make believe.

I totally agree, but that doesn't mean mocking isn't a great tool to have in the proper context.

Functional tests are not one of those.

I started to leave a comment and found I had too m...

2008-12-11T12:09:00.000-05:00

I started to leave a comment and found I had too much to say to respond properly here, so I posted my response on my blog. Feel free to comment here or there if you're interested in a dialog about this.

The short version is that it makes sense that mocking won't work for you because it is an isolation technique and your approach favors integration.

The long version is at http://blog.davidchelimsky.net/2008/12/11/a-case-against-a-case-against-mocking-and-stubbing.

Cheers,
David

I've used SQLite memory databases for many apps an...

2008-12-11T11:43:00.000-05:00

I've used SQLite memory databases for many apps and the speed was on par with using MySQL through a native driver.

As the Merb guys say, "No code is faster than no code."

Here is a project that is attempting just what you...

2008-12-10T18:57:00.000-05:00

Here is a project that is attempting just what you suggest using TreeTop as the SQL parser:
http://github.com/smtlaissezfaire/guillotine/

re: your argument
All points are valid but you seem to leave off the design benefit of mocking which is the primary reason to use them. Also, if you have stories (Cucumber features) driving your entire process like you say those will catch any breaks in between the layers. That said both approaches are valid with pros and cons to each.