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
on 2008-06-23 19:15
on 2008-06-23 20:28
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
on 2008-06-23 20:45
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
on 2008-06-23 21:50
> 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