Skipping decorators in unit tests

[Ethan Furman]

On 10/10/2013 08:01 PM, Roy Smith wrote:
> On 10Oct2013 19:44, Ned Batchelder <ned at nedbatchelder.com> wrote:
>>> 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.
>
> In article <mailman.978.1381459605.18130.python-list at python.org>,
>   Cameron Simpson <cs at zip.com.au> wrote:
>> 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.
>
> And there lies the fundamental white-box vs. black-box testing conundrum.
>
> The black-box camp (whose flag Ned is flying) says, "There is an exposed
> interface which accepts certain inputs and promises certain outputs.
> That's all you know, that's all you ever can know, and that's all you
> should ever want to know.  The interface is constant.  The guts can
> change without notice".  That's a perfectly valid philosophy.
>
> The white-box camp (under which banner Cameron rides) says, "There's a
> lot of neat stuff under the covers, and I can do a better, faster, and
> more complete testing job if I take advantage of my knowledge of what's
> under the kimono".  That, too, is a valid philosophy.

Some tests can also be done much more easily with white-box.  Imagine an 
edge case which takes an exact that requires an exact, seldom used, 
sequence of events because an internal bug is usually counteracted by 
the rest of the system, except in some small number of cases.  Directly 
testing the internal piece directly for the bug can be much easier than 
setting up the long and involved test.

--
~Ethan~