Hi Alexei,
On 12/7/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
Alexander,
It is great that you started this work. Please, excuse my dumb
questions, I just want to understand the subject and its correlations
to other activities better
1. Does you patch capture an output from crashed VM? This would be
quite useful, because VM prints a native stack trace when crashes.
It can but it does not. Now it just reports about failed test case.
2. I support Alexei's question about functional differences between
Vladimir's approach and your one. As for now I more or less understand
why Vladimir's solution is good (simple and catches crashes with zero
return code), and understand why it is bad (it doesn't capture VM's
output).
Other laks of his approach are: it does not capture the situations
when JVM crashed before creation of xml file (there are such tests)
and it does not report test case made JVM crash (only JUnit test class
name). Although I agree - his aproach is simpler.
3. Can your solution be extended to modes other than perTest (for
example, to test reliability on simple cases)?
Yes, it is possible to implement, but now I do not see the sense of
doing it. If one test in a bundle causes JVM crash there won't be a
chance for other test (in a bundle) to be executed.
4. You wrote,
> Note that H000 regression test is failed because of DRLVM crash.
Have I missed something? What is this H000?
This is an example of regression test placed under
src/test/regression/H000 directory. Now there is no corresponding JIRA
report for it. I'm going to remove it when I finish infrastructure (and
file new JIRA report if there is no such).
5. Is there anything Harmony specific in your task? Could it be useful
for Ant project?
JUnit test format is not supposed to handle JVM crashes. So I think it
is Harmony specific. Particularly to its VM part.
6. Is it difficult to add handling of test decorators in a following way?
<junitperf fork="false">
<decorator class="junit.extensions.RepeatedTest">
<ctorarg test/>
<ctorarg intvalue="${junit.extensions.repeatedtest.repetions}"/>
</decorator>
<test name="org.apache.ecs.InternationalCharTest" />
</junitperf>
I don't know exactly, but first ideas coming in my head are:
- extending of a JUnitRunner class to execute decorator with a unit
test as a parameter
- extending of JUnitTask to handle nested <decorator> elements
and to configure command line to be launched).
(I just oticed that posted this example privately).
To my mind idea is quite promising, and I even have started to
interfere with your field. You could think of a decorator which
preallocates a big amount of memory and runs given tests in the rest
of the heap space, or a decorator which runs GC in parallel, or even a
decorator which runs all tests on a finalization thread.
I put two coffees for the fact that the last decorator to class
library unit tests would produce many interesting DRLVM artifacts and
JIRA issues.
I agree, it is a good idea!
Alexander, thanks again for starting this job! All, thank you for
reading up to this point. :-)
Thank you for your interest! I think at the moment I've got everything
I needed from <junit> task. If there is a person who is willing to
continue these improvements I'll happy to help him.
Alexander
