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):
> >def g(y):
> > . . .
> >f.g = g#
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):
> . . .
>f.g = g# make g vis
[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 is the
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
larger function.
My te
