db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: JUnit
Date Wed, 02 Mar 2005 18:27:51 GMT
Jeremy Boynes wrote:

> Daniel John Debrunner wrote:
>> I have been experimenting with Junit, but that needs its own thread.
> So here we go :-)
> 
> What are your opinions so far?
> 
> I would be in favour of a gradual transition to JUnit based testing due
> to the familiarity many developers have with it. 

 Here are some additional reasons I think JUnit would be good:

      -  Get rid of exising harness code

      -  Simple model should lead to significantly faster testing times
as the JUnit model is to run the tests within the same JVM. The nist
tests run in the exising harness like this and they are significantly
faster than they used to be.

      - move away from "master file" based testing to assert based
testing, though it may require up front writing of utilites that handle
validating result set output. Ie the test provides the expected output
of the result set in some array form and a utility handles comparing
that to the result from Derby, including factoring out any ordering
differences.


My concerns with JUnit are its platform coverage, and I just haven't
looked into this. Will it run on JDK 1.3, J2ME/CDC/Foundation, OSGi
ee.minimum, Z/OS etc.  Would that community be willing to support those
platforms?

> Although migrating the
> current ".java" tests may be fairly easy, migrating the ".sql" tests
> would seem a much larger task.

All the exisitng Derby tests compare the output from the test (on
System.out) to known correct output. Within the Java tests there may be
additional assert type checks, but they are tested by printing different
output.

I actually wrote a really simple JUnit aimed at the .sql tests, I
ignored several items the Derby harness does, just to get an idea of how
it would work. Each .sql test is a JUnit test and a ran as a suite of a
handful of tests. The main differences between this and the existing
Derby harness are:

    - tests run within the same JVM
    - tests run against the same database, I was too lazy to write code
to drop the old database or clean it up, but that's simple coding work.
    - test output is not written to disk, except when the test fails
    - compare with master file works on line by line and fails at the
first difference. Thus on failure a developer would most likely use diff
to see how the test really failed.

It is example (quick hack) code, it could be generalized (probably
through multiple test classes) to handle .java tests and others.

Examples of items the harness does that I didn't address were setting up
the properties files associated with some tests, sed'ing the output to
remove variance, copying across additional files.

I looked at about 10 language .sql tests and about 6 passed within this
environment. Some failed due to the lack of the sed operation, though
that in itself was interesting. I'm not a great fan of the sed approach,
too much potential for failures to be sed'ed out. The insert test only
failed because the existing harness was sed'ing out a timestamp, but
that timestamp was constant, so there was no need for a sed. Some failed
due to the lack of a clean database to start with (again, because I was
to lazy to write the cleanup code).

I have to leave for a flight back to the West coast now, once I'm back
on-line I'll see if I can find my test code.

Getting JUnit to run would be a good project, that does not require
database internal knowledge, I'm unlikely to spend any more time on
coding this.


Dan.






Mime
View raw message