On 10/10/2013 08:01 PM, Roy Smith wrote:
On 10Oct2013 19:44, Ned Batchelder <n...@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-l...@python.org>,
Cameron Simpson <c...@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~
--
https://mail.python.org/mailman/listinfo/python-list
