Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #56702 > unrolled thread

Re: Skipping decorators in unit tests

Started byNed Batchelder <ned@nedbatchelder.com>
First post2013-10-11 14:53 -0400
Last post2013-10-11 14:53 -0400
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Skipping decorators in unit tests Ned Batchelder <ned@nedbatchelder.com> - 2013-10-11 14:53 -0400

#56702 — Re: Skipping decorators in unit tests

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-10-11 14:53 -0400
SubjectRe: Skipping decorators in unit tests
Message-ID<mailman.1013.1381517615.18130.python-list@python.org>
On 10/10/13 10:22 PM, Cameron Simpson wrote:
> On 10Oct2013 19:44, Ned Batchelder <ned@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.

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web