in reply to RFC: Tutorial "Introspecting your Moose code using Test Point Callbacks"
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".
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: RFC: Tutorial "Introspecting your Moose code using Test Point Callbacks"
by ait (Hermit) on Jan 02, 2011 at 18:23 UTC |