Re: RFC: Tutorial "Introspecting your Moose code using Test Point Callbacks"

[roboticus]

alt:

I agree with the points that ELISHEVA and zwon raised.

My primary objection is that it makes the object API less well defined. While there are exceptions, typically a method is "atomic". But with callbacks, objects may be altered in mid-operation causing interactions you won't be able to anticipate, and thus you can't create tests for beforehand. Also, normally innocuous changes that you'd make could break user code.

Finally, if you don't consider the placement of your callback locations, algorithm improvements may become extraordinarily difficult, as you'd have to maintain the illusion that callbacks are executed at the appropriate time. For example, if you have an iterator class and it searches linearly through your list. It provides a "next item" callback for each item considered. If the container is sorted, then the user may expect that the "next item" callback will be called in ascending order. In your next version, you want to use a binary search to speed things up. But now the "next item" callback won't be executed in order, and you'll be skipping items. Your callback interface locks you into a linear search or you'll break someone's application.

Is there some compelling scenario you've encountered that makes this better than simple static testing? When I was reading it, the best case I could come up with is to provide hooks for logging rather than testing. I'd be interested in seeing how you use it.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Update: added "and zwon".

[ait]

Thank you for your feedback.

As I point out to ELISHEVA in a lengthy response above, I am using this technique specifically to test parts of a method, not at all to supply a call-back mechanism or pre/post/around hooks of any sort (which BTW are already provided by Moose). The idea is to inspect intermediate results in a single function, much like many times you leave a DB breakpoint, a commented warn statement, or a debug-level log statement, is probably because you anticipate having problems there in the future, or because these intermediate results may help you to debug this code if a test fails.

Rationale: whenever you have the need to print a debug statement, or use the debugger, is is not better to write a sub-test case with this call-back technique?

Of course this may only apply to complex functions that cannot be factorized into smaller chunks, for example long nested conditionals, etc. If you don't use these callbacks they don't really hurt and could even be wrapped with a 'diagnostic' testing mode for example. So you can run your basic tests, and if the fail, you could run a more thorough 'diagnostic' test that uses the callbacks to evaluate intermediate results.