harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general][tests]To restrict the side-effect of junit tests by launching it in a different VM.
Date Wed, 29 Nov 2006 00:16:50 GMT
Leo,
Could you please share more info about the problem?

Could you please name a test case which affects other test cases? I
have tried to check http://issues.apache.org/jira/browse/HARMONY-2249
but it doesn't contain any clue.

Why this test case cannot be fixed to clean environment on exit?
-- 
Thank you,
Alexei


On 11/29/06, Leo Li <liyilei1979@gmail.com> wrote:
>  Anyway, using exec, the test is running in a standalone java program rather
> than the normal junit test.:)
>
> On 11/28/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> >
> > On 11/28/06, Leo Li wrote:
> > >
> > > OK. It will do in exec, but the style is a little different.:)
> >
> >
> > Sorry, I didn't catch - what "different style" means here?
> >
> > Thanks,
> > Stepan.
> >
> > And I also believe run most tests in one VM will save time.(Actually it
> > > has been quite long currently.)
> > > I just want to denote the tests that should run in seperate VM while
> > > remaining the style of junit tests except some configurations. (Like
> > > something in AOP and without intruding.)
> > >
> > >
> > > On 11/28/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > > >
> > > > Stepan Mishura wrote:
> > > > > On 11/27/06, Leo Li wrote:
> > > > >>
> > > > >> Hi, all:
> > > > >>     During fixing the bug of Harmony-2249, I found that the
> > testcase
> > > in
> > > > >> one
> > > > >> junit test file might lead to other fail in a different junit
file.
> > > > After
> > > > >> digging into it, I am aware that testcase can influence the global
> > > > state
> > > > >> of
> > > > >> a VM, for example, the resolution of class (both RI and Harmony
> > have
> > > > >> similar
> > > > >> behavior). Although I changed the testcase as a workaround, 
it is
> > > not
> > > > >> tested so thoroughly as I expected in order not to lead other
tests
> > > to
> > > > >> fail.
> > > > >
> > > > >
> > > > > If a test's execution influence of VM state and this is critical
for
> > > > other
> > > > > test then the test can fork VM (via Support_Exec.execJava()) and
do
> > > all
> > > > > testing in the forked VM.
> > > >
> > > > +1 -- and this should be the exception, in general tests should put
> > > > things back as they found them.  exec'ing a new Java is for those
> > cases
> > > > where you cannot do that.
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > >
> > >
> > >
> > > --
> > > Leo Li
> > > China Software Development Lab, IBM
> > >
> > >
> >
> >
> > --
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>
>


-- 
Thank you,
Alexei

Mime
View raw message