On 19 May 2008, at 17:57, John D. Hume wrote:
I do that sort of thing pretty often.
I would just point out that you should avoid calling that mocking,
since there are no expectations in place and therefore no
verification of the specific way the code being specified interacts
with the MigrationGraph. According to the definitions in Mocks Aren't Stubs(which
are apparently from http://xunitpatterns.com/ but I haven’t read
it), your hash is a ‘fake’ MigrationGraph.
I hope you will forgive my sloppy use of TDD terms 
Actually I’ve never liked the use of the word “mock” to mean “verified
stub” or something similar, as “mock” and “fake” are synonyms in
everyday English. Maybe that’s because in RSpec you can create
expectations on any object (blank mocks or arbitrary other objects).
After all consider these two snippets (which is condensed from how you
would write real code):
@store = mock(“store”)
@store.stub!(:[]).and_return(1, 2) # implies you know the order of
calls
@store.should_receive(:[]).with(“a”).and_return(1)
@store.should_receive(:[]).with(“b”).and_return(2)
@store = { “a” => 1, “b” => 2 }
@store.should_receive(:[]).with(“a”).and_return(1)
@store.should_receive(:[]).with(“b”).and_return(2)
Only one is a mock by definition, but most sane code (and specs) would
behave the same with either. Surely since they both quack, they are
both ducks? As for the terms in the Fowler article, this is how I feel:
- Dummy - I’m ok with this, I use symbols as dummies all the time
- Fake - an “in-memory database” isn’t fake, it’s just an
implementation that satisfies the needs of the code at hand (ie the
spec). You could say a single-server database is fake, if a load-
balanced cluster is needed to satisfy availability requirements.
- Stubs - I think of a stub as a message-level concept, not an object-
level one. To me, an object with stubs could be called a “fake” since
it could never be used for a real purpose, no matter how simple the
real task.
- Mocks - in RSpec these are just objects that complain if sent an
unexpected message. They become fake (my sense of the word) objects
when you stub responses on them, although I prefer to call them mocks.
Alternative words that might make more sense in a duck-typed language
are “substitute” instead of “fake” (that’s what the use of a Hash
about would be) and “mock” instead of “stub”. I don’t know what you’d
call a Fowler mock in that case - maybe the idea doesn’t make sense
when any object can have expectations. I also don’t know what you’d
call a partial mock - an aberration, perhaps?
I’m sure this is all nit-picking, but it’s taken me two years to learn
the “official” words and they still feel unnatural (which is why I
always fall back to my own version).
End rant!
Ashley
PS I think my use of a substitute Hash above is actually a symptom of
violation Tell Don’t Ask, I should probably pass the names of the
migrations to the MigrationGraph and have it unapply them all. That
would also clean up some other really hideous code in the Apply class
where #run goes poking around deleting stuff inside the graph (it’s a
did-I-really-write that moment). I wish I had the foresight to do
things right in the first place!
–
http://www.patchspace.co.uk/