Typically, you would not have listeners check the ordering since they probably cannot fix it
This is actually my favorite point! Sending messages in the correct order is of course the framework's concern - it seems I've been overthinking it somewhat.
You might use a fluent API which returns a new type of object that only allows certain actions
That's basically what I've been doing - but it seems like a dead end, as explained, since the fluent API only guarantees "A before B", which is only a small part of the problem.
Or a usage pattern that automatically calls End events when the method goes out of scope.
I thought about this, but it won't really work - or at least won't always work correctly. For some listeners, it's important to know when the stream of events ends - for example, a profiler needs to know precisely when a test-case ends, an XML reporter needs to write after the last Test Suite, and so on.
Anyways, thank you for reminding me to focus on the right problems here :-)
Oh, I see. I was thinking about the framework process (calling with fluent API or self-closing usage), not the listener. You are right, these methods won't work for listener code. Happy to participate. :)
Thanks for all the ideas :-)
This is actually my favorite point! Sending messages in the correct order is of course the framework's concern - it seems I've been overthinking it somewhat.
That's basically what I've been doing - but it seems like a dead end, as explained, since the fluent API only guarantees "A before B", which is only a small part of the problem.
I thought about this, but it won't really work - or at least won't always work correctly. For some listeners, it's important to know when the stream of events ends - for example, a profiler needs to know precisely when a test-case ends, an XML reporter needs to write after the last Test Suite, and so on.
Anyways, thank you for reminding me to focus on the right problems here :-)
Oh, I see. I was thinking about the framework process (calling with fluent API or self-closing usage), not the listener. You are right, these methods won't work for listener code. Happy to participate. :)
Yeah, the idea is to create an API for listeners that is largely framework-neutral. I've simplified it quite a bit tonight :-)