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,
Richard
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
