Skipping decorators in unit tests

[Ned Batchelder]

On 10/10/13 10:22 PM, Cameron Simpson wrote:
> On 10Oct2013 19:44, Ned Batchelder <ned at nedbatchelder.com> wrote:
>> On 10/10/13 6:12 PM, Cameron Simpson wrote:
>>> Speaking for myself, I would be include to recast this code:
>>>
>>>    @absolutize
>>>    def addition(a, b):
>>>        return a + b
>>>
>>> into:
>>>
>>>    def _addition(a, b):
>>>        return a + b
>>>
>>>    addition = absolutize(_addition)
>>>
>>> Then you can unit test both _addition() and addition(). [...]
>> I have to admit I'm having a hard time understanding why you'd need
>> to test the undecorated functions.  After all, the undecorated
>> functions aren't available to anyone.  All that matters is how they
>> behave with the decorators.
> If the undecorated function is buggy, the decorated function will
> be buggy. But the bug will be harder to resolve, and if you're
> especially lucky the decorator will often-but-not-always conceal
> the bug in the inner function.
>
> Wanting to test the core function is perfectly reasonable. You can in
> principle write simpler and more direct tests of the core function.
>
> Having an error report that points directly at an error instead of
> an error report that points at some outer dysfunction (i.e. "somewhere
> deep inside here something is broken") is highly desirable in
> general, and therefore also in a test suite.
>
> Cheers,

I understand the desire to test the inner function.  But the OP said "I 
need to...", which makes me think he's dealing with some kind of "mock a 
service, but the service is in the decorator, so what should I do?" 
situation.  In which case, there might be a better solution than 
undecorating the function.

--Ned.