Geir Magnusson Jr. wrote:
Why not use junit?
If you mean why not use junit to loop over tests, then it is not the
case. I've used junit to do this in my work.
The loop which I wrote here is the loop over components in the build.xml
of drlvm. If you run "build smoke.test" you'll see that the same tests
are repeated several times (you have to be patient to see this). This is
done because build loops over all known VM components like vmi, vmocode,
gc, interpreter, etc. It is Ok for building, and it is done exactly for
building, but it is not Ok for testing because repeating tests for the
whole JVM for each of its components makes no sense.
Gregory Shimansky wrote:
On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:
Gregory,
I observed similar quirks with paths while intergrating kernel tests
into build. AFAIU the "Grand Design" is the following: there are
abstracted targets and isolated component descriptors; build system
iterates through all components and tries to apply given target to
each component. So there are various tricks to stop it running tests
multiple times a-la "recurring inclusion protection" in C headers.
I do not grok how it calculates dependencies though, but it is quite
easy to drive it mad and it starts doing wrong sequence of targets and
picks wrong components etc.
So I just snipped off that fanciful machinery and made simple subant
for "kernel.test" target - see its definition in build/make/build.xml,
and compare with nearby "smoke.test" one.
Ok I've made it though all of the interesting ant tricks and created
my own jvmti.test target. I noticed the difference of how kernel.test
target is included into build.xml as compared to smoke.test or unit.test.
AFAIU only "test" target does actually work to run only once and for
the required number of modes (jit, interpreter). This is done with a
special workaround for "test" target in build.xml, it has its own
processing. But inclusion of smoke.test and unit.test in build.xml
right now makes it run in a loop for all components for which tests
don't have any relation to.
I am still experimenting with the build, it might be I'll find a
solution for individual test categories so it would be possible to run
them separately from the general "test" target.
--
Gregory
