harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [testing] metadata approach
Date Thu, 17 Aug 2006 03:08:31 GMT
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.

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

Paulex Yang
China Software Development Lab

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