harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Date Thu, 02 Nov 2006 14:21:16 GMT


Gregory Shimansky wrote:
> 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).

You're joking, right?  I do this for ever patch commit I do.

> 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.

You're joking here too, right?  How do you know if there aren't side 
effects among components?

geir

> 
>> 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.
>>>
>>
> 
> 

Mime
View raw message