Fixing reporters/listeners

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fixing reporters/listeners

Phillip Ross-2

Quick poll for anyone who invokes TestNG programatically, are you happy with the way listeners work right now?

I was trying to do something very simple today, to extend the email reporter to output to a HttpServletResponse writer. This is conceptually trivial, as all I have to do is specify a different writer and create the reporter with the http response.

All is not well however with the tng API. It only allows me to specify classes of listeners, rather than instances. This is problematic because it removes any ability to control the instantiation of the listeners from the caller, and so it's impossible to write stateful listeners. It also makes it difficult to embed tng and wire up its dependencies.

In fact, this lack of stateful listeners has resulted in another smell, the fact that the generateReport callback for example takes in an output directory. It's easy to imagine a ton of reports that don't need or care about this (email, remote publishing, db reports, aggregating reporters, as a few examples), yet it's there in the API presumably to get over the fact that stateful listeners aren't possible.

So, hopefully you'll all sold on the problem, now to sell my solution:

- Deprecate TestNG.setListenerClasses(Class[])
- Add setListeners(Object[]). As an aside, it'd be nice to have a top level marker interface for I*Listener and IReporter so we can have something more type safe that Object[] passed in.
- Change the default listener registration so the caller creates the instances, rather than passing in classes

For bonus points:
- Change the listener interfaces to not have outputDir, and instead to modify the built in listeners to be stateful and to take in the output dir as a parameter (maybe with the introduction of a common superclass, FileBasedListener).

The last change would be non backward compatible, as it'd change the method signatures for the listeners. So we might shy away from that depending on how many use it. The first two points however seem very easy to do and are backward compatible. If there's no objection, I'd be happy to implement these changes. Thoughts?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=64775&messageID=124323#124323

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Fixing reporters/listeners

Alexandru Popescu ☀

On 2/15/07, Hani Suleiman <[hidden email]> wrote:

>
> Quick poll for anyone who invokes TestNG programatically, are you happy with the way listeners work right now?
>
> I was trying to do something very simple today, to extend the email reporter to output to a HttpServletResponse writer. This is conceptually trivial, as all I have to do is specify a different writer and create the reporter with the http response.
>
> All is not well however with the tng API. It only allows me to specify classes of listeners, rather than instances. This is problematic because it removes any ability to control the instantiation of the listeners from the caller, and so it's impossible to write stateful listeners. It also makes it difficult to embed tng and wire up its dependencies.
>
> In fact, this lack of stateful listeners has resulted in another smell, the fact that the generateReport callback for example takes in an output directory. It's easy to imagine a ton of reports that don't need or care about this (email, remote publishing, db reports, aggregating reporters, as a few examples), yet it's there in the API presumably to get over the fact that stateful listeners aren't possible.
>
> So, hopefully you'll all sold on the problem, now to sell my solution:
>
> - Deprecate TestNG.setListenerClasses(Class[])
> - Add setListeners(Object[]). As an aside, it'd be nice to have a top level marker interface for I*Listener and IReporter so we can have something more type safe that Object[] passed in.
> - Change the default listener registration so the caller creates the instances, rather than passing in classes
>
> For bonus points:
> - Change the listener interfaces to not have outputDir, and instead to modify the built in listeners to be stateful and to take in the output dir as a parameter (maybe with the introduction of a common superclass, FileBasedListener).
>
> The last change would be non backward compatible, as it'd change the method signatures for the listeners. So we might shy away from that depending on how many use it. The first two points however seem very easy to do and are backward compatible. If there's no objection, I'd be happy to implement these changes. Thoughts?
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=64775&messageID=124323#124323
>

Have you checked TestNG:

addListener(ISuiteListener)
addListener(ITestListener)
addListener(IReporter)

?

./alex
--
.w( the_mindstorm )p.
  TestNG co-founder
EclipseTestNG Creator

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Fixing reporters/listeners

Hani Suleiman

Alexandru Popescu wrote:
>
> Have you checked TestNG:
>
> addListener(ISuiteListener)
> addListener(ITestListener)
> addListener(IReporter)
>
Hah! Very cunning, yeah this is exactly what I need. The issue still
stands though with the output dir API, any thoughts about changing that?
Though I guess most listeners that don't care about it now can keep on
ignoring it like they do.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Fixing reporters/listeners

Alexandru Popescu ☀

On 2/15/07, Hani Suleiman <[hidden email]> wrote:

>
> Alexandru Popescu wrote:
> >
> > Have you checked TestNG:
> >
> > addListener(ISuiteListener)
> > addListener(ITestListener)
> > addListener(IReporter)
> >
> Hah! Very cunning, yeah this is exactly what I need. The issue still
> stands though with the output dir API, any thoughts about changing that?
> Though I guess most listeners that don't care about it now can keep on
> ignoring it like they do.
>

I will recheck the rest of the email and answer shortly.

./alex
--
.w( the_mindstorm )p.
  TestNG co-founder
EclipseTestNG Creator

> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en
-~----------~----~----~----~------~----~------~--~---