On 2011.10.25 12:29 AM, Eric Wilhelm wrote:
> I like the sound of plan B, except for the "stores itself in" combined
> with "swap me out".
Any specific doubts?
> Can the event coordinator keep a stack? At the point where the parent
> handler has to tell the coordinator "swap me out", you could have the
> coordinator providing the functionality which you were thinking of
> getting from the delegator.
That's an interesting idea. It certainly could happen. The two problems are
A) it constrains what an event watcher can do (see below) and B) the subtest
watcher still has to communicate its results back to the parent watcher.
B could be solved by the event coordinator doing the swap and then asking the
subtest history to generate a result event summarizing the subtest. The
parent watchers (which are now swapped in) will see that. Come to think of
it, that sort of thing is nice and clean no matter who is doing the swapping.
But I don't see a solution to A.
What the event coordinator could do to help is keep track of the subtest depth
and add that onto events. Then nothing else has to worry about setting or
tracking that, they just ask the event.
>> The code to handle the creating and swapping of a subtest could be put
>> in the event handler superclass.
>
> Would that be for convenience of reuse or because an essential part of
> the API is the freedom to override that method and do it differently?
> I think putting this in the coordinator would allow fewer surprises.
Both. For example, I can easily imagine a history or event logger that wants
to record the whole test as a tree.
Part of the point is to provide maximum flexibility to test module authors, so
we're not stuck with design mistakes 10 years later, while still retaining a
system that's easy to use if you do things as expected.
--
44. I am not the atheist chaplain.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
