harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [classlib][test] Migration to testNG?
Date Mon, 16 Jun 2008 07:30:55 GMT
Sure, We could define different @group for particular excluded list on 
different platform,
and run them separately when we needed.

Best Regards,
Regis.

Tim Ellison wrote:
> I haven't looked at TestNG, so I don;t have a strong opinion either way.
> 
> Does TestNG allow you to produce a report of all tests tagged as 
> @excluded (or whatever)? so we can easily see which tests are excluded | 
> run on a particular platform | whatever?  I would think that'd be useful.
> 
> Regards,
> Tim
> 
> Sean Qiu wrote:
>> Interesting. So we can upgrade to Junit 4.4 more smoothly or without 
>> any pains.
>> But what can we benefit from the upgrading?
>> Get 6 annotations to run tests and  hamcrest assertions.
>> IMHO, this can not solve any of our problems that TestNG can.
>>
>> Or we wait until Junit 4 include groups annotations?
>>
>> 2008/6/13 Nathan Beyer <ndbeyer@apache.org>:
>>> On Thu, Jun 12, 2008 at 10:13 PM, Sean Qiu <sean.xx.qiu@gmail.com> 
>>> wrote:
>>>
>>>> 2008/6/12 Sian January <sianjanuary@googlemail.com>:
>>>>> This is slightly off track, but my concern about TestNG is that 
>>>>> there are
>>>>> already quite a lot of steps for someone new to Harmony to get the 
>>>>> source
>>>>> code and run the tests (both for the whole of Harmony and for a single
>>>> class
>>>>> library module).  Certainly for Eclipse users if we switched to TestNG
>>>> this
>>>>> would add another step, although I'm not sure about command-line 
>>>>> users.
>>>>>
>>>> The cost to make use of current tests is low, IMHO.
>>>> I have mentioned that we can add TestNG target to replace Junit target.
>>>> From the command-line users'  perspective, they still use the same
>>>> command to run the test.
>>>> The only difference would be the command will invoke TestNG to run our
>>>> test.
>>>> For Eclipse users, they can adopt plug-in for TestNG, it is quite the
>>>> same as plug-in for junit.
>>>> So I think we can migration to TestNG smoothly for the user.
>>>> What's more, they can pick up their desired tests more conveniently.
>>>>
>>>> For test developers,  on the other hand, it is a little complex.
>>>> But  we want to upgrade to a new tool, no matter Junit 4 or TestNG, we
>>>> need to pay for it.Their efforts are similar.
>>>
>>> Actually, we can use JUnit 4 now. If you run with Ant 1.7 and put the 
>>> JUnit
>>> 4 library that's in the dependency download already into your Ant 
>>> classpath,
>>> JUnit 4 tests will run. You can even mix JUnit 3 and 4 tests in the 
>>> same run
>>> and it works fine, so new test classes can be built at JUnit 4 tests 
>>> without
>>> having to update any existing test code. You can even use some of the
>>> minimal built-in hamcrest matchers, as they are part of the JUnit 4.4 
>>> JAR.
>>>
>>> -Nathan
>>>
>>>
>>>> For TestNG, we need add annotations for each testcase, classify them
>>>> to right groups.
>>>> The good news is we still can use original assert* as before since
>>>> TestNG include JUnit's Assert class.
>>>> As Nathan mentioned , we can use hamcrest as well if we want.
>>>>
>>>>
>>>>
>>>>> Of course if switching to TestNG solves some really major problems 
>>>>> then
>>>> it
>>>>> would probably be worth it, but the only thing I can see that it 
>>>>> gives us
>>>>> over JUnit 4 is being able to run different sets of tests on different
>>>> OS's
>>>>> and to me that doesn't seem as important as having a project that's 
>>>>> easy
>>>> to
>>>>> access.  Just my 2p worth...
>>>>>
>>>> We can replace the exclude files  to get a more accurate tracking for
>>>> failed test.
>>>> We can tell difference between public API tests and harmony specific
>>>> implementation tests .
>>>> We can archive all tests together into a jar.
>>>> I think there should be other benefits as well :)
>>>>
>>>>
>>>> -- 
>>>> Best Regards
>>>> Sean, Xiao Xia Qiu
>>>>
>>>> China Software Development Lab, IBM
>>>>
>>
>>
>>
> 

Mime
View raw message