harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [testing] metadata approach
Date Tue, 22 Aug 2006 10:51:17 GMT
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!


> [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,

Oliver Deakin
IBM United Kingdom Limited

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