Re: Test Harness useprocess=false question

[Myrna van Lunteren <m....@gmail.com>]

John,

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

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.

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

http://mail-archives.apache.org/mod_mbox/db-derby-user/200512.mbox/%3c82dc60e00512110508u68b10785ne6d7fb2b1612e476@mail.gmail.com%3e

and reply:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200512.mbox/%3c439D513C.4020108@Sun.com%3e

I'm wondering if this wouldn't be a nice thing to have after all...? A
washwombat() method? 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?
Myrna


On 11/20/05, John Embretsen <Jo...@sun.com> wrote:
>
> Friday, November 18, 2005, 8:31:28 PM, Myrna van Lunteren wrote:
>
> >> On 11/18/05, John Embretsen <Jo...@sun.com> wrote:
>
> >> Are there other cases (other than the nist tests) where we should be
> >> able to run with useprocess set to false?
> >
> >
> > As I need to use useprocess for DERBY-413, I am cleaning up the tests
> > in derbynetclientmats (which includes jdbcapi, jdbc20 and jdk14 suites),
> but I'm not going beyond.
>
> OK, so are you running into InstantiationExceptions anywhere? I noticed
> that with useprocess=false, the main method of the test class is invoked
> through reflection. RunTest.java calls RunClass.java, which does this by
>
> mainMethod.invoke(testClass.newInstance(), arguments);
>
> Now, the call to newInstance() will fail if the test class does not
> include a (public) nullary constructor, or because of some other issue
> (see JavaDoc for java.lang.Class). A simple solution to this problem (I
> know that some java tests does not include such a constructor) would be
> to pass "null" instead of "testClass.newInstance()" to the invoke
> method, since the method called (main) is static anyway... ("If the
> underlying method is static, then the specified obj argument is ignored.
> It may be null.", from JavaDoc for java.lang.reflect.Method.invoke(...)).
>
> --
> John
>
>

Re: Test Harness useprocess=false question

[Kristian Waagan <Kr...@Sun.COM>]

Daniel John Debrunner wrote:

>John Embretsen wrote:
>
>  
>
>>Myrna van Lunteren wrote:
>>    
>>
>
>  
>
>>>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 think I've seen an extension to Junit called something like DBUnit
>that has this functionality, to clean up databases between Junit tests.
>I'm not sure what licence it is under, but it may be another reason to
>spend move effort on moving to Junit.
>
>Dan.
>  
>
Just for the record, DBUnit is distributed under the LGPL license.
For a quick description of how DBUnit can be used, have a look at 
http://dbunit.sourceforge.net/howto.html.



--
Kristian

Re: Test Harness useprocess=false question

[Daniel John Debrunner <dj...@debrunners.com>]

John Embretsen wrote:

> Myrna van Lunteren wrote:

>> 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 think I've seen an extension to Junit called something like DBUnit
that has this functionality, to clean up databases between Junit tests.
I'm not sure what licence it is under, but it may be another reason to
spend move effort on moving to Junit.

Dan.

Re: Test Harness useprocess=false question

[John Embretsen <Jo...@Sun.COM>]

John Embretsen wrote:

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

Myrna,

For some reason, I did not get any e-mails from Jira with your comments 
  to DERBY-413 (could not find it in the derby-dev archives either), but 
I got the "[jira] Resolved" e-mail. I see you have implemented my 
suggestions in the patch that was committed by Andrew. Thanks for doing 
the work! :)


-- 
John

Re: Test Harness useprocess=false question

[John Embretsen <Jo...@Sun.COM>]

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


-- 
John