Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Sender: Ned Batchelder <nedbat@gmail.com>
Date: Fri, 11 Oct 2013 14:53:24 -0400
From: Ned Batchelder <ned@nedbatchelder.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Cameron Simpson <cs@zip.com.au>
Subject: Re: Skipping decorators in unit tests
References: <52573BED.40305@nedbatchelder.com> <20131011022218.GA97623@cskk.homeip.net>
In-Reply-To: <20131011022218.GA97623@cskk.homeip.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gilles.lenfant@gmail.com, python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1013.1381517615.18130.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:56702

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.