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

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

Re: Skipping decorators in unit tests

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 Cameron Simpson <cs@zip.com.au> - 2013-10-11 13:22 +1100
    Re: Skipping decorators in unit tests Roy Smith <roy@panix.com> - 2013-10-10 23:01 -0400
      Re: Skipping decorators in unit tests Ethan Furman <ethan@stoneleaf.us> - 2013-10-11 10:46 -0700

#56635 — Re: Skipping decorators in unit tests

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,
-- 
Cameron Simpson <cs@zip.com.au>

They shouldn't get any new nuclear weapons until they've used the ones
they've got.    - Murff

[toc] | [next] | [standalone]

#56639

On 10Oct2013 19:44, Ned Batchelder <ned@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@python.org>,
 Cameron Simpson <cs@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.

[toc] | [prev] | [next] | [standalone]

#56699

On 10/10/2013 08:01 PM, Roy Smith wrote:
> On 10Oct2013 19:44, Ned Batchelder <ned@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@python.org>,
>   Cameron Simpson <cs@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~

[toc] | [prev] | [standalone]

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

csiph-web