harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [testing] metadata approach
Date Wed, 23 Aug 2006 08:07:46 GMT

Oliver Deakin wrote:
> Paulex Yang wrote:
>> Just a wild thought, because TestNG support both jre142 and jdk5, so 
>> there must be some way to make it run with annotation but without 
>> concurrent, just have a look at the layout of TestNG[1] source code 
>> from its v4.1 release, seems if we replace the 
>> src/jdk15/org/testng/internal/thread/*.java with 
>> src/jdk14/org/testng/internal/thread/*.java, and rebuild it, there is 
>> chance to create a customized version based 
>> edu.emory.mathcs.util.concurrent as workaround. If no one 
>> objection(say, legal consideration), I can try this thought.
> That's interesting - I don't know about the legal considerations, but 
> I'd like
> to hear how your experimentation goes!
Hello Oliver,

I have tried Paulex's solution, and I can launch simple TestNG test 
using HarmonyVM. But I doubt if this is necessary. Maybe we will have 
concurrent soon :-)

Nathan, could you share some information about concurrent?

Best regards,

> Regards,
> Oliver
>> [1] http://testng.org/testng-4.1.zip
>> Alexei Zakharov wrote:
>>> Hi Oliver,
>>>> But is j.u.c actually required to be in the runtime under test? I was
>>>> thinking
>>>> that j.u.c was only required for the VM actually running the harness,
>>>> and all
>>>> that gets run on the VM under test is the actual test method. If this
>>>> was true,
>>>> then we could run TestNG with the RI (which has j.u.c) and use the
>>>> jvm option to specify the Harmony VM (which would not need j.u.c).
>>> I afraid we cannot do like that. At least I was not successful last
>>> time I tried to run tests using the jvm="<harmony>" option. As far as
>>> I understand TestNG requires j.u.c for running every single test
>>> method  because parallel running can be specified on the method level.
>>> I mean in TestNG you can write something like this:
>>> @Test(threadPoolSize = 7, invocationCount = 29)
>>> This means that this method should be invoked from different threads.
>>> And it seems that TestNG needs j.u.c to implement multithreading.
>>>> Yes agreed, it is good to make group membership explicit as it 
>>>> facilitates
>>>> inclusion/exclusion of groups, and makes it obvious which group tests
>>>> belong to. Perhaps the same should be done for api tests, so we have a
>>>> type.api group?
>>> So you suggest to add @Test (groups={os.any, type.api}) to every api
>>> test (that runs on every platform) without any defaults at all?
>>>> I thought I had sent a mail out on this in the original thread, but 
>>>> I guess
>>>> I never did (unless Thunderbird is hiding mail from me again!).
>>> Just checked - there is no such mail in my gmail box, at least in the
>>> "[classlib] Testing conventions - a proposal" thread.
>>>> So, for example, if we were on a Windows x86 32bit machine, the Ant
>>>> scripts would run test groups "os.shared", "os.windows", 
>>>> "os.windows.x86"
>>>> and (if we ever get any 32/64bit specific tests) 
>>>> "os.windows.x86.32bit",
>>>> or something similar.
>>> Well, I like it in general. The only thing I still feel uncomfortable
>>> with is "os.shared". When some code is shared among different
>>> platforms it makes sense. But here we have a test shared by several
>>> OSes. Does this sound natural? But I don't feel strongly about that
>>> and will not object if everybody likes this.
>>> With Best Regards,

Richard Liang
China Software Development Lab, IBM 

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message