Raymond Hettinger wrote:
> [Benji York]
>
>>Note that when using this technique, f.g will not be bound until after
>>you call the function:
>
>
> That is a feature, not a bug. The inner function isn't even created
> until the outer function is run.
I'm fully aware of that. I just didn't want
> > [Andy]
> >>How can you unit test nested functions?
[Raymond Hettinger]
> > For whitebox testing, you could make an inner function visible by
> > binding it to the enclosing function's attribute namespace.
> >
> >def f(x):
> >
Raymond Hettinger wrote:
> [Andy]
>>How can you unit test nested functions?
> For whitebox testing, you could make an inner function visible by
> binding it to the enclosing function's attribute namespace.
>
>def f(x):
>def g(y):
> . . .
[Andy]
> How can you unit test nested functions? Or do you have to pull them out to
> unit test them, which basically means I will never use nested functions.
Several commons use cases (closures and factory functions) ultimately
expose the inner function through the return value. If that
Andy wrote:
> How can you unit test nested functions?
I can't think of a good way. When I write a nested function it's because
the function uses variables from the scope of the function in which it's
embedded, which means it makes little sense to test it independent of the
la
How can you unit test nested functions? Or do you have to pull them out to
unit test them, which basically means I will never use nested functions.
Also, same thing with private member functions protected by __. Seems like
there is a conflict there between using these features and unit
