db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject Re: Some thoughts on new version testing.
Date Tue, 14 Nov 2006 17:56:24 GMT
On Tue, 14 Nov 2006, Greg Monroe wrote:

> ...
> 1) The test-project properties can have a lot of
> different build properties, such as: beans/nobeans;
> idBrokerMethod; managers/no manager; and the like.
>
> It seems like we should have an agreed upon set of
> test run properties that need to be used against a
> database type to say it's truly passed the tests.
> In other words, the test-project needs to be run
> several times against a DB with each run having a
> different set of properties, E.g. with Beans, with
> Beans/Managers, with native/idBroker methods,
> and the like.
>
> There's a lot of combinations, so which ones make
> sense?

Probably most of the combinations make sense. However, I'm rather sure 
that most of the combinations need not be run against a particular 
database; any db will do. The Beans stuff falls into this category, and 
I'd guess also the managers (Thomas V, correct me if I'm wrong). Plus we 
could test the enableJava5Features setting. Other properties like setting 
complexObjectModel=false, correctGetters, subpackageXXX etc can probably 
not be tested by the test project (at least not in its current state).


> 2) Should there be semi-standardized reporting of
> Test-project runs with new version RCs?  I.e., ask
> folks to test it against their DB, and then send
> in a report with OS, JVM, DB Version, JDBC Driver,
> and results of each test run type?

Yes, that is the intent of the test project. However, if I remember 
correctly, some people have had difficulties setting up the test project 
(e.g. you need to install maven first). So, I'd guess it will always be 
the Torque developers which will do most of the testing.

And I'd not rely too much on the test project. It is grown much better in 
the last two years, but test coverage is still not very good. We will 
probably also have to rely on bug reports by users as in the past.

> 3) Should there be a core of required DB's that have
> to be tested and pass before a version is released?
> E.g., MySQL, Derby ('cause we're part of the DB
> project!), Postgres, Oracle, DB2, and MS SQL/Sybase
> come to mind.  DB2 is the only one I haven't seen
> mentioned here in a while.

I'd guess no current Torque developer has a DB2 installation ready. After 
a quick research, there is a free edition (called Express-C) of DB2, which 
I'll try to install in the next few days.
Personally, I'm currently testing against Mysql, Postgresql, Derby, 
Hsqldb, Oracle, and Firebird.

>
> 4) Do we want to "publish" this info anywhere?  E.g.,
> in the final version release notes have a list of
> DB versions, JDBC versions that Torque was tested
> against before release.

Hm, we might update the supported databases page
http://db.apache.org/torque/releases/torque-3.2/docs-all-components/supported-databases.html
to display that information.

>
> FWIW, if we can decide on the set of test run
> criteria, I'll take a pass at doing an Ant script
> to set up the conditions and call Maven to do the
> tests against a DB in one step.  (Probably can do
> this with a Maven uber project, but I can do it
> faster in ant then figuring out the Maven property
> inheritance quirks.)

If you want to do that- great ! However, I'd not put too much effort in 
this. Personally, I'd like to switch the build process to maven 2 in 4.0
(of course that's open to discussion !!!), so the effort might get lost.

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message