db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: Test Harness useprocess=false question
Date Fri, 16 Dec 2005 15:44:40 GMT
Myrna van Lunteren wrote:

> John,
> I found that indeed, using mainMethod.invoke(null,arguments) was 
> required and worked well. Thx.

I'm glad to hear that!

I noticed that you included this code change in your (rather large) 
patch for DERBY-413. One consequence of this code change is that the 
first parameter to RunClass.java ("Class theClass") is not used or 
needed anymore, hence it should be removed (I don't think you included 
this in your patch). This means that the classes instantiating a 
RunClass object (RunTest.java at least, any others?) also need to be 
modified somewhat. I guess it looks cleaner if we do this in a separate 
patch - maybe even creating a new Jira issue - or what do you think?

I also think that it would not hurt adding some more comments to 
RunClass.java. But, of course, there are limits to how much effort one 
should put into feeding a dying horse...

> I did modify a few tests classes to be public rather than have the 
> default package protection in addition, for the above approach did not 
> get around that limitation.
> I did not investigate all tests in the derbynet(client)mats suites - 
> which includes jdbcapi, multi, jdbc20 and jdk14 suites, but most. I did 
> not run into any test that did an unfortunate System.exit in this bunch.

OK, that's good. I'll let the list know if I find more issues, but it's 
not likely that I'll be looking very hard.

> Still, even in those suites, there will still be a few tests that cannot 
> run ok with useprocess=false because they leave 'stuff' behind. I 
> probably spend most of the time working on this patch making individual 
> tests run 'clean'.
> I've been thinking a method to clean up databases actually would be 
> really nice. We could hang it in RunTest.execNoTestProcess(). That way 
> we could run more tests with useprocess=false, and speed up the test 
> run. Recently a user also asked for this functionality...

[snipped links]

> I'm wondering if this wouldn't be a nice thing to have after all...? A 
> washwombat() method? 

Absolutely, I was wondering whether such a method existed somewhere 
already myself, until I saw the e-mail you referred to.

> I'm imagining it to be tricky though, 'd have to 
> cycle through metadata calls and loop to remove views and triggers etc 
> before tables... and ensuring no attempts at removing system stuff are 
> made... Anyone any thoughts on this?

I'm afraid I must pass on this for now - but I'm sure other people on 
this list have the knowledge required to give some sensible input...


View raw message