db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject [Running] Top-level junit tests - WAS Re: [jira] Commented: (DERBY-3316) Leak in client if ResultSet not closed
Date Sat, 19 Jan 2008 00:30:16 GMT
Myrna van Lunteren wrote:
> I hadn't realized the ant junit-all target has gotten to be more than
> suites.All.

This wiki page has details of various top-level JUnit tests.

http://wiki.apache.org/db-derby/DerbyTopLevelJunitTests

> I want to point out that to run platform tests it's not always
> possible to use ant - not all OSs or machines I try to run on during a
> platform test have ant available.
> So if another solution can be found than relying on junit-all I'd appreciate it.

It's not really relying on ant, the junit-all target just provides a 
mechanism to run a set of tests, just as suites.All provides a mechanism 
to run almost the same set of tests.

There's no requirement for anyone to use ant junit-all or suites.All.

In addition there's nothing stopping anyone from contributing another 
mechanism to run tests, e.g. a script file, a different grouping of 
tests etc.

The advantage of using ant or a Junit suite is that they are standard 
mechanisms, and thus the tests can be run by other tools easily, such as 
Elipse, junit test runners or cruise control. E.g. I was running 
junit-all in cruise control as a continuous build process (like the 
tinderbox runs), since it's all standard tools cruise control 
automatically handled success/failure of the build and test runs and 
provided a useful web-interface to the junit test results, which was 
more readable than the home grown scripts that run the nightlies at the 
moment. E.g. a series of dots [....] doesn't tell me which tests were 
run and which took the longest, whereas the xml output does :-).
I even added a target in build.xml that others could use for a 
continuous build - 'cibuild'.

Dan.



Mime
View raw message