Forum: Rails Spinoffs (closed, excessive spam) unit test and mocking functions

Posted by Justin Perkins (Guest)
on 2008-06-23 19:15
(Received via mailing list)
I'm curious if anyone has written an add-on to unittest to support
mocking-like behavior for functions so that we can write assertions
that ensure a function is called within other functions.

If this hasn't been done, I thought it'd be pretty straight forward to
add a assertCall() method to the Test.Unit.Assertions class, which
would just wrap a function, but then the question is: once I wrap a
function, can I unwrap it?

-justin
Posted by kangax (Guest)
on 2008-06-23 20:28
(Received via mailing list)
I haven't seen anything like this (prototype-based).
Unwrapping function is possible, but not in current Function#wrap
implementation. You could either store a reference to original
function as a property on a new (wrapped) one, or use a separate id-
based table for mapping one function to other ones. I find first
approach better. If every wrapped function has pointers to both
"previous" and "next" versions, you basically get a doubly-linked list
(and could easily walk in both directions)

- kangax
Posted by Justin Perkins (Guest)
on 2008-06-23 20:45
(Received via mailing list)
On Mon, Jun 23, 2008 at 1:27 PM, kangax <kangax@gmail.com> wrote:
>
> Unwrapping function is possible, but not in current Function#wrap
> implementation. You could either store a reference to original
> function

Shortly after sending my original message, I realized that all I need
to do is store the reference before wrapping it. It'd be nice if
Function#wrap somehow encapsulated that functionality for us, though
it probably wouldn't be terribly handy for day-to-day usage.

I'll let you know what I come up with.

-justin
Posted by kangax (Guest)
on 2008-06-23 21:50
(Received via mailing list)
> Function#wrap somehow encapsulated that functionality for us, though
> it probably wouldn't be terribly handy for day-to-day usage.

Justin, it actually would : )
How many times have you output the string representation of any of
Element#methods(those which are directly on an element) just to see:

"function () { return __method.apply(null,
[this].concat($A(arguments))); }"

That's the job of #methodize, but you get the idea.

We were actually considering changing Function#wrap to accept optional
boolean parameter. It would indicate that "wrapped" function's
toString must be bound to an original function's toString. This is
often crucial for debugging.

- kangax
This topic is locked and can not be replied to.