Yeah, I have no problem writing my own.  However, if this is to be
expected of TestNG users to get similar output as previous versions of
surefire, then it should be WELL documented as such.

My issue is that the behavior changed between surefire versions.  This
caused all kinds of confusion for developers at my company, they needed
the latest version of testng to support some functionality, but they had
to use the latest surefire to use the latest testng and all of a sudden
the output completely disappeared.  The frustrating part is the maven
developers who worked on surefire claimed it was because of the way
testng worked and that there was nothing they could do about it.  With
very little effort, by reading the TestNG JavaDoc and looking at the
surefire code to see that they simply didn't implement the methods that
would have kept the behavior the same.

This frustrates me and everyone at my company to no end. Slowly, but
surely Maven and the ASF are being looked at as software lacking in
quality, both within my company and in the Java community as well, as
top respected people in the community (who shall remain nameless in this
post) "rant" about the errors with maven implementation quite often and
speak about how the concept is good, but the implementation has been
anything but good and this leads to other conclusions about the way ASF
and the Maven project are being run as a whole.

This is most unfortunate.

This has turn into a "rant" from me, but I think it is worthwhile to
have the maven developers hear critical feedback from time to tome.

-----Original Message-----
From: P'Simer, Dana (Matrix) [mailto:Dana.P'[EMAIL PROTECTED] 
Sent: Thursday, March 20, 2008 6:39 AM
To: Maven Users List; Maven Developers List
Subject: RE: surefire and testng integration issues with surefire-2.4.2

I have recently been dealing with a similar issue.  I wanted Junit style
reports and did not want to use ant run to run the JunitConverter task,
so I added reportng as a test scoped dependency and configured a
listener.  

As an interim solution, you could write a listener that does what you
want.  It could just be in your src/test/java dir as classes there will
be available to TestNG when it is running so there is no need to create
a separate jar, unless you want to.  To configure it you would do
something like this:

...
    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      ...
      <configuration>
        ...
        <properties>
          <name>listener</name>
          <value>x.y.z.MyNiftyProgressOutputter</value>
        </properties>
        ...
      </configuration>
      ...
    </plugin>
...

The listener properties's value can be a comma separated list of classes
so if you have more than one, you can do that.

Good Luck,

Dana H. P'Simer
Dana.P'[EMAIL PROTECTED]

-----Original Message-----
From: Jason Chaffee [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 20, 2008 5:32 AM
To: Maven Developers List
Cc: Maven Users List
Subject: surefire and testng integration issues with surefire-2.4.2

I brought this up in the past the maven guys were adamant that they were
not able to get per test information to output on the console unless
testng changed.  I felt all along that this was not correct and I
finally had a chance to look into it.  Surefire could simply register a
listener to get call backs during the execution and could output the
results.  TestNG does support this functionality with the ITestListener.
For example, onStart() will give the start of running a particular class
configuration and test methods and onFinish() will be called after all
of the configuration and test methods have been run.  I took a look at
the Surefire code and there is a TestNGReporter that does implement the
ITestListener, but it does not implement these methods, they are all
no-ops.  So, it seems like these could be implemented and then we could
see progress output on the console. 

 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to