(Surprisingly?) I find mocking AR (DM less so) in specs extremely
Having said this, I find the approach of top-down VCM speccing very
legitimate (cucumber for V, rspec for C, and probably unit tests for M).
That is, a model is an inherent though separate part of the controller
trying to spec just the controller lacks efficiency (pragmatism) and
Therefore, I’ve starting working on
http://github.com/costa/rspec-orm(everything is of concept-quality
there, including the name). It’s already
“working for me”.
I think the README there pretty much cuts it, so I’d just welcome the
Note that â€” I’m sorry â€” the code is not only unpackaged, but it is in a
separate http://github.com/costa/dev/tree/master/ruby/ in part (for a
Again, any feedback is appreciated.
I’m sorry, I’d like to clarify my statement about the model, view and
controller (spec) separation.
From my perspective, model is an abstract definition which is a spec
for itself; view interacts with controller under the model contract,
and all the “model” code is actually low-level controller code which
makes the high-level code work. Alternatively, it can be trivially
said that the database state is equivalent to a sequence of controller
Hence the inclination to see the least model-related code in specs.
On 21 Jul 2010, at 10:28 PM, Costa Shapiro wrote:
(Surprisingly?) I find mocking AR (DM less so) in specs extremely tedious and intrusive.
Yeah, I know what you mean, I just don’t do it any more. I find the
pain isn’t worth it on the stuff I do.
I think the README there pretty much cuts it, so I’d just welcome the comments here.
One very minor point, you’re got a comment to maybe empty the database
afterwards. It’s more useful to empty it before, as then you’ve still
got the data in the database after a failing example.
Also, if you haven’t seen it, Ben M. wrote a tool for this. Oh
and I wrote one for rebuilding your database if migrations change,