Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

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

by roboticus (Chancellor)
on Jan 02, 2011 at 16:05 UTC ( #880082=note: print w/replies, xml ) Need Help??

in reply to RFC: Tutorial "Introspecting your Moose code using Test Point Callbacks"


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.


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

Update: added "and zwon".

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

Replies are listed 'Best First'.
Re^2: RFC: Tutorial "Introspecting your Moose code using Test Point Callbacks"
by ait (Friar) on Jan 02, 2011 at 18:23 UTC

    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://880082]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (2)
As of 2018-03-25 01:39 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (299 votes). Check out past polls.