Andreas Korneliussen wrote:

> It seems to me that for including a new JUnit test into i.e derby-all we
> need to make a new java class with a main() method, which parses a
> command line and set up the testsuite and run it, just like any java
> program. Basically we are running the junit tests as test type "java".
> 
> Instead of having to do this for every junit test going into a derby
> test suite, I would propose a different strategy.
> 
> I propose to introduce a new test type called "junit" (current test
> types are: sql,sql2,unit,java,multi,demo - unit is not junit)
<snip>

Sounds good.

Is there any write up of the correct way to write new Junit tests?
I think a big mistake we made with the old harness was no formal way to
add Java tests, which meant multiple ways to start the engine and obtain
the connection and multiple utility methods (almost) performing the same
action.

Would be nice if there were guidelines provided by whoever set up the
initial Junit framework.

It would also be great if there was some documentation on how the tests
are expected to run. Looking at DerbyJUnitTest I can't understand why
there is static state, such as _databaseName, I though Junit tests were
objects?

Dan.

Reply via email to