db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manish Khettry <manish_khet...@yahoo.com>
Subject Re: JUnit testing moving forward
Date Thu, 20 Jul 2006 21:47:09 GMT
This is related to the matter of testing but somewhat
tangential to the issue being discussed. 

I am really interested in understanding if Derby is
amenable to unit testing. By unit testing I mean
testing at a class or package level instead of at a
system level which most of the tests do currently,
atleast for the sql layer functionality.

There are many benefits to testing a unit as opposed
to  the entire system. For one you don't have to
create a database, create and populate objects
everytime you want to test something. Thinking about
testing a class or package leads to better and more OO
design. It also means more comprehensive tests imho.

Take for example the result set implementations in
sql/execute. If we could mock out the store
functionality we could test them more comprehensively
with unit tests than what we do currently-- we could
mock large amounts of data through them; we could also
exercise code path that one-shot executions from ij
don't exercise. 

Not to say that we don't need system tests or the
existing tests are not good enough. I can see that
given the complexity of the code base and how tightly
coupled many of the packages and classes are, this is
hard but is this something to keep in mind as we are
writing code and tests?

And on the issue of using ant-- why not have ant
targets in java/testing to run standard suites? much
easier to get a developer to type "ant derbyall" and
have it do the needful (setup classpath, invoke the
right class) than what we do currently. This could be
done right now and ease the pain for new developers
trying to work with Derby.


--- Daniel John Debrunner <djd@apache.org> wrote:

> Rick Hillegas wrote:
> > There are lots of good suggestions in this
> message. I would add the
> > following: If we're going to consider a new test
> harness, then we could
> > evaluate using Ant to drive the junit tests. Ant
> already has an optional
> > <junit> task for this purpose.
> Maybe I wasn't clear, the new harness should be
> JUnit itself, not
> something wrapped around JUnit. Then we get all the
> benefits of Junit
> for free, integration with ant, IDEs, tests
> understood by others, etc.
> Dan.

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

View raw message