[mocha-developer] mocking missing methods
dchelimsky at gmail.com
Wed Apr 25 17:29:01 EDT 2007
On 4/25/07, James Mead <jamesmead44 at gmail.com> wrote:
> Hi Dan, David, and any other interested parties,
> I've just been looking into implementing this and have come up with a
> few issues. It'd be great to have some feedback.
> In Dan's sheep example, you want to constrain the mock to only respond
> like an instance of the Sheep class. For completeness I think we
> should allow you to constrain the mock to only respond like the Sheep
> class itself. I've been playing with some possible syntax...
> sheep = mock()
> sheep_class = mock
How about ....
sheep = mock()
sheep_class = mock
> As you can see I'm also inclined to avoid overloading the parameters
> of the mock() method any more - hence the responds_like() method.
> What do you think about the instance_of() method?
> What do you think about the responds_like() method?
> I like Dan's idea of raising a NoMethodError at invoke time, but I'm
> wondering if I should extend the message slightly to avoid confusion
> if you've actually set up an expectation for the non-existent
> sheep = mock()
> sheep.foo # => NoMethodError: undefined method `foo' for
> #<Mock:0x456edc> which responds like instance_of(Sheep)
> What do you think about the extension to the exception message: "which
> responds like instance_of(Sheep)"?
Based on my suggestion above, I'd like "which responds like Sheep" or
"which response like Sheep.class".
This is all just a matter of detail and style. However it lands, I do
like the overall idea of having #responds_like and having support for
classes and instances. The suggestion I'm making seems to align more
w/ the notion of "class as object" (i.e. we're either dealing w/ an
instance of Sheep or an instance of Sheep.class - but either way we're
talking about how an instance of something behaves).
> mocha-developer mailing list
> mocha-developer at rubyforge.org
More information about the mocha-developer