3 ms·

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 classmet

by temuze 12y ago

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.

deleted 12y ago
[deleted]
sinkasapa 12y ago
It sounds like the testing frameworks in Python must be very limited if this is true.
- raverbashing 12y ago
  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-function-within-a-functionnested-function http://stackoverflow.com/questions/7054228/accessing-a-funct...
- kstrauser 12y ago
  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.)
  - sinkasapa 12y ago
    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?
    - kstrauser 12y ago
      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.
raymondh 12y ago
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).
Walkman 12y ago
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.
- csirac2 12y ago
  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.

by temuze 12y ago

deleted 12y ago

[deleted]

sinkasapa 12y ago

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

raverbashing 12y ago
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-function-within-a-functionnested-function http://stackoverflow.com/questions/7054228/accessing-a-funct...
kstrauser 12y ago
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.)
- sinkasapa 12y ago
  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?
  - kstrauser 12y ago
    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.

raymondh 12y ago

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).

Walkman 12y ago

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.

csirac2 12y ago
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.