db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1141) test harness usage of useprocess needs improvement
Date Wed, 19 Apr 2006 08:50:11 GMT
Myrna van Lunteren wrote:
> On 4/18/06, *John H. Embretsen (JIRA)* <derby-dev@db.apache.org 
> <mailto:derby-dev@db.apache.org>> wrote:

[snip - details and useprocess=false discussion]

> 
>     JUnit and useprocess=false:
>     ----------------------------------------------------
> 
>     Some may be surprised to find that junit tests are run in a separate
>     process by default (instead of being skipped) when useprocess=false.
>     However, I think I see some advantages of doing it this way, so I
>     accept (a bit reluctantly, perhaps) this behavior for now.
> 
>     In the patch I also find:
> 
>     -        if ( useprocess )
>     +           // Always create a process if testType is junit,
>     otherwise testRunner
>     +           // would exit a suite prematurely, and we can't debug
>     that anyway and
>     +           // they should run quick anyway.
>     +        if ( useprocess || (!useprocess && testType.equals("junit")))
> 
>     I'm not sure I understand/remember exactly why junit tests cannot be
>     run with useprocess=false ( i.e. why "testRunner" (I assume this
>     means junit.*ui.TestRunner) would exit a suite prematurely). Feel
>     free to educate me on this subject (otherwise I guess I'll look into
>     it myself when time permits) ;)
> 
>  
>  
> Yes, I was referring to junit.*ui.TestRunner. I wanted to enable as many 
> test as possible when running useprocess=false, and I thought skipping 
> the junit test would be an increasingly bad idea as we'd get more and 
> more junit tests...
>  
> So I experimented running the junit test as a separate process (I just 
> copied how they're run when useprocess=true (the default)), the first 
> junit test ran successfully and that was all that ran, the entore 
> RunSuite process just stopped. I assumed that TestRunner must be doing a 
> System.exit() somewhere. Maybe I was off with that conclusion/assumption...

I think you are correct with your conclusion/assumption. A quick grep of 
the JUnit source code (3.8.1), shows matches for System.exit in all of 
textui.TestRunner, swingui.TestRunner and awtui.TestRunner.

Since we would want a text/console based test runner, we may have to 
write our own if we want to run JUnit tests with useprocess=false.
When looking at the source of textui.TestRunner, I don't think this 
would be a very different task. It might even be possible to do a quick 
hack, but I do not know if this is allowed according to the license 
(CPL) or if we want to do this.

Can anyone with knowledge of CPL (Common Public License - v 1.0) shed 
some light on what we can and can't do?



--
Kristian

>  
> I think for now, I will make the harness skip junit tests when 
> useprocess=false. I'll double check the code to make sure there's no 
> left-over comments suggesting they're getting run.
>  
> Myrna
>  
>  


Mime
View raw message