Kristian Waagan wrote:
Myrna van Lunteren wrote:
On 4/18/06, *John H. Embretsen (JIRA)* <[email protected]
<mailto:[email protected]>> wrote:
[snip - details and useprocess=false discussion]
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.
Thank you all for your explanations, I appreciate it very much!
After reading your replies yesterday I decided to get more familiar with the
JUnit source code and how it all works. After experimenting a little (outside
the derby test harness), I think I found a way to run junit tests with
useprocess=false, without implementing a custom TestRunner.
The solution involves reflection, kind of like the way regular java tests are
invoked with useprocess=false in the test harness.
Please let me know if I am misunderstanding something or making wrong
assumptions in the follwing:
It is sometimes desirable to create your own suite using a static suite()
method, returning a TestSuite object, in order to use suite-specific test
decorators etc. See
http://www.nabble.com/-jira-Created%3A-%28DERBY-918%29-introduce-a-new-test-type-to-run-junit-tests-from-the-current-harness-t1053121.html#a2850250
When running "junit.textui.TestRunner <testClass>" (as a stand-alone process,
useprocess=true) junit extracts the TestSuite (extending from Test) from the
suite() method if there is such a method, and runs it.
If there is no such method, the JUnit TestRunner (in
junit.runner.getTest(...)) creates a suite which includes all methods
starting with "test", and runs this instead.
I am assuming that we want the same behavior when running with useprocess=false.
Since the TestRunner.main() method contains System.exit() calls, I suggest
invoking junit by:
a) Passing the TestSuite object returned from the suite() method to
junit.textui.TestRunner.run(), if such a suite() method exists.
or
b) (if a suite() method does not exist) Passing a new TestSuite object to
junit.textui.TestRunner.run(), perhaps as shown in the old code comments in
RunTest.java shown in the nabble thread referred to above. This suite will
contain all methods starting with "test" in the test class.
If this sounds acceptable, I can try to get this to work with the derby test
harness and (if successful) provide a patch for it.
--
John
