Anyway, using exec, the test is running in a standalone java program rather than the normal junit test.:)
On 11/28/06, Stepan Mishura <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) > > 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
