Skipping decorators in unit tests

Roy Smith roy at panix.com
Thu Oct 10 23:01:43 EDT 2013


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.

We now return to reality, already in progress.



More information about the Python-list mailing list