Hacker News Reader

Comment by temuze | Hacker News Reader

My problem with inner functions is that you can't create a unit test for them. They're inaccessible.

I would propose making your inner function into a classmethod and moving away from the state of the class. This structure is well defined and is easily testable.

Alternatively, assuming you feature doesn't get more complicated, you can make your min-max ordering happen in one line:

    self.minimum, self.maximum = sorted((minimum, maximum))

I think you can avoid self hell through careful programming.

View on HN

Inner functions in closures are tested in much the same way as methods are tested for classes.

   closure = OuterFunc(var1, var2)
   self.assertEqual(closure(var3), result)

   inst = SomeClass(var1, var2)
   self.assertEqual(inst.somemethod(var3), result)

When you think about it, there isn't much sense to calling an inner function without having called the enclosing function (the inner function typically depends on data trapped or closed by the outer function).

Likewise, there isn't much sense in calling a method without having instantiated a class (methods typically depend on data stored in the instance).

You don't test inner functions the same way as you don't test private methods in a class. You only test for public API. They are implicitly tested when you test the higher level function.

Typically I would agree with you, but I've worked on a lot of old codebases with extensive testing for deep scary private parts. A good example is some public method which does something seemingly innocent and useful, but in its guts calls a bunch of black magic to deal with different operating systems and configuration options.

It sounds like the testing frameworks in Python must be very limited if this is true.

They're limited in the sense that they can't magically reach into a scope and inspect its private variables.

(Not technically true - deep code inspection is possible. That wouldn't be the same as unit testing, though.)

Why would you need to do this for a unit test? Can't you just test the properties of the return value of the outer function like you would for any other value? If the function returned an object, how would that be different?

OK, I think some wires got crossed. You can trivially create a unit test for the outer function that indirectly tests the output of the inner function. What the GGP meant was that you can't directly test the inner function because you can't access it and so can't call inner() from the unit test.

For example, given:

  def add(a, b):
      def inner():
          return a + b
      return inner()

You can write tests like:

  assert add(1, 2) == 3

But you can't write something like:

  assert add.inner() == 3

If inner() were doing something nontrivial, you'd probably want it to be standalone.

It's not about the testing framework, it's about not being able to access the inner function

http://stackoverflow.com/questions/7054228/accessing-a-funct...

Reply on news.ycombinator.com