specing candied objects
Piotr Szotkowski
objects that include Candy::Piece / Candy::Collection (when I don’t
want to spec the persistence but something else)? Try to stub out
the dependency? Ignore it and let the specs roam on a temp database?
Something else?
On a related note: if I want to have a certain environment for
specing (say, a large-ish fixture), what would be the best way
to do this? A mongodump/mongorestore binary fixture (bleh)?
A mongoexport/mongoimport JSON fixture? Something else?
— Piotr Szotkowski
--
I’m happy for people to hold negative views of programmers. I just
ask them to avoid hypocrisy by not using the internet to express them.
[Paul Battley]
Stephen Eley
<chas...@chastell.net> wrote:
> As long as I’m on the roll – what’s the best (canonical…?) way to spec
> objects that include Candy::Piece / Candy::Collection (when I don’t
> want to spec the persistence but something else)? Try to stub out
> the dependency? Ignore it and let the specs roam on a temp database?
> Something else?
Wow, that's a really good question. I would prefer to stay away from
'canonical' answers (I think 'canon' in this community is too often
treated like its homonym, and used to shoot holes in other people's
craft) -- and, uh, on top of that, I hadn't really thought about it
yet. The way I've done specs with Candy so far has been to use a test
database. I won't defend that as the _best_ way, and it does have its
risks (Mongo can have glitchy timing when you need to verify things
across two different connections); but it was the path of least
indirect effort.
I'm thinking now about whether you *could* stub out the persistence
parts, and I think with the current code base it'd be unreasonably
tough. It might get easier once Crunch is fully integrated, because
the points of database contact will be better-defined; but even then,
I don't think it would be trivial. The downside of an ORM with no
explicit DB calls is that you don't have obvious points to stub.
You'd have to get underneath it and stub some of the inner workings.
Would a "Mongo-less" Candy be a good idea? For testing and other
purposes? Maybe. I don't know. The behavior of a Candy::Piece
object is different enough from a Plain Old Ruby Object that I doubt
it can just be factoried in. (I'd say it's a bit like an OpenStruct
on acid.) Abstracting that interface and removing it from its Mongo
dependency has an appealing whiff to it -- but it's also a really big
idea, with some philosophical implications beyond just specs, and I
need to nail done some of the current architectural Big Idea overhauls
before I could consider taking on a new one. >8->
> On a related note: if I want to have a certain environment for
> specing (say, a large-ish fixture), what would be the best way
> to do this? A mongodump/mongorestore binary fixture (bleh)?
> A mongoexport/mongoimport JSON fixture? Something else?
I'd say yes to either notion. They're both good (and basically
equivalent) ways to take a static copy of a MongoDB data store. In
one project I even had a Rake task that would call the Mongo
copyDatabase() command and clone my production database on demand --
but that was more useful for staging and integration testing, not
development and unit specs.
--
Have Fun,
Steve Eley (sfe...@gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
Piotr Szotkowski
> On Wed, Aug 25, 2010 at 11:09 AM, Piotr
> Szotkowski <chas...@chastell.net> wrote:
>> As long as I’m on the roll – what’s the best (canonical…?) way to
>> spec objects that include Candy::Piece / Candy::Collection […]?
> Wow, that's a really good question. I would
> prefer to stay away from 'canonical' answers
Ah, the perils of electronic mail and invisible smileys…
> The way I've done specs with Candy
> so far has been to use a test database.
Ok, that’s a very reassuring answer (finally, a time
when I *didn’t* miss an obvious solution to a problem!).
> The downside of an ORM with no explicit DB calls
> is that you don't have obvious points to stub.
Well, turning that around – the upside of transparent persistence
is that you don’t even *try* to stub it out, it’s just there…
>> On a related note: if I want to have a certain environment for
>> specing (say, a large-ish fixture), what would be the best way
>> to do this? A mongodump/mongorestore binary fixture (bleh)?
>> A mongoexport/mongoimport JSON fixture? Something else?
> I'd say yes to either notion. They're both good (and basically
> equivalent) ways to take a static copy of a MongoDB data store.
Ok, I’ll play with these, then. :)
— Piotr Szotkowski
--
It’s 8:21 AM, do you know where your process is? Call
0-800-GREP to find out more how YOU can prevent zombification.
[opi]