Hi Alex,
some ways we can achieve this. Do we want to finish deciding that before the migration, or are we confident that we will get to a point where a decision is made and we can start transitioning beforehand?
Well, IMHO adding some extra javadoc tag will not break anything. There are situations when you need some sticker just to put on test to mark it as "implementation specific" for example since you will forget everything in a week. I currently use some javadoc text like "This test is highly implementation specific" or "@impl" tag to mark such tests. But I would prefer to do it in a more standardized way. ABout finishing deciding: we probably need to engage more people in the discussion ...
Lastly, do we have entries (e.g. on the wiki) about how to write new tests that are either (a) compatible with JUnit+TestNG, or (b) use TestNG alone? It seems like this would be a good way to ensure new tests are TestNG-compatible and thus increase the coverage of TestNG tests.
I don't think we have anything concerning TestNG on the wiki right now. IMHO we still need everybody to accept the intention of moving to the new harness before starting this activities. We probably also need to have pointers at least for how to run
the tests from My Favourite IDE (tm) and/or the build itself.
AFAIK there are TestNG plugins for Eclipse and IDEA but I haven't tried it yet.
Are there any other systems e.g. JUnitReport that we need to consider for this? Does TestNG's reporting suit what we want to do and/or can we leverage any of the reporting that it does on the web?
Basically TestNG built-in reporting system produces all necessary information. But the resulting report doesn't look very nice and I don't know how to customize it. Funny thing: the report looks nicer in Mozilla than in IE. On the other hand, the use of JUnitReport is "officially approved" by TestNG team - i.e. TestNG produces all necessary input stuff for JUnitReport. JR is more powerfull report-generation system, we may customize it's output with XSL sheets if we like (AFAIK). The default style of reports generated by JUnitReport looks nicer. Regards, 2006/7/28, Alex Blewitt <[EMAIL PROTECTED]>:
> The question I'd like to raise now is – aren't we ready for TestNG > right now? For example, we could replace our harness from jUnit to > TestNG and lazily start converting of some failing and platform > dependent tests to javadoc version of TestNG. > > Thought? Suggestions? Opposite opinions? I think that if the decision is made to go down the TestNG route (and my hope is that we will) then this sounds like a good approach. Of course, everyone would have to be happy at the migration (sounds like we're heading towards a vote on it) and like you say, we can always use the TestNG harness to run the existing set of JUnit tests, so we should still be in the same position. As for the metadata decisions (e.g. platforms) there still seems to be some ways we can achieve this. Do we want to finish deciding that before the migration, or are we confident that we will get to a point where a decision is made and we can start transitioning beforehand? Lastly, do we have entries (e.g. on the wiki) about how to write new tests that are either (a) compatible with JUnit+TestNG, or (b) use TestNG alone? It seems like this would be a good way to ensure new tests are TestNG-compatible and thus increase the coverage of TestNG tests. We probably also need to have pointers at least for how to run the tests from My Favourite IDE (tm) and/or the build itself. Are there any other systems e.g. JUnitReport that we need to consider for this? Does TestNG's reporting suit what we want to do and/or can we leverage any of the reporting that it does on the web? Alex.
-- Alexei Zakharov, Intel Middleware Product Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
