Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of Greg.Monroe@dukece.com
 designates 65.112.55.73 as permitted sender)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Some thoughts on new version testing.
Date: Wed, 15 Nov 2006 16:16:47 -0500
Message-ID: <8F5843B903F59D4C8C6806BB49A3911901E92738@dukece-mail3.dukece.com>
In-Reply-To: <20061114093040.G75088@minotaur.apache.org>
Thread-Topic: Some thoughts on new version testing.
Thread-Index: AccIFkCatyMpRBAiRFuA6BH4Eyw1ywA1+TFg
From: "Greg Monroe" <Greg.Monroe@DukeCE.com>
To: "Apache Torque Developers List" <torque-dev@db.apache.org>

Here's some further thoughts on this:

There seems to be three major testing categories here:

DB Specific Tasks (Need to run against major DBs):
  SQL generation, et. al.
  A subset of standard code tests like limits, like=20
     escaping, booleans, and the like.
  Autoincrement/idBroker methods.
  And a general all tests work.

OM Code Generation Variations (DB indendent)
  Major functional items, like managers, beans, etc.
  Minor functional items, like add addSaveMethod, etc.

Code Structure Options
  Package names
  Object prefixes
  Timestamping

Code Structure Options

I'll start with Code Structure items.  These can be tested
for the most part by simply defining non-standard values=20
(because we'd know already if the defaults didn't work)
to these options and verifing that they compile and pass=20
the test (mostly just compile). =20

There is also an secondary test for them in the fact that=20
some test case code references the OM classes and won't=20
compile if these packages don't match.

These options can be set permanently in the test-project
project.properties file and never modified.  All test=20
run will "validate" them.

Here are the options I'd put in this category. =20

  torque.targetPackage
  torque.subpackage.peer
  torque.subpackage.object
  torque.subpackage.map
  torque.subpackage.manager
  torque.subpackage.bean
  torque.subpackage.base
  torque.subpackage.base.bean
  torque.basePrefix
  torque.BeanSuffix
  torque.addTimeStamp (Just to check for compile problems)

DB Specific Tasks

The DB specific stuff can probably be handled by running two=20
standard tests against the DB similar to:

Test1: =20
  torque.test.base.idMethod =3D idbroker
  torque.generateBeans =3D true;
  torque.useMangers =3D false;
  torque.objectIsCaching =3D false;

Test2:
  torque.test.base.idMethod =3D native
  torque.generateBeans =3D false;
  torque.useMangers =3D true;
  torque.objectIsCaching =3D true;

These should validate the SQL generation and catch any major
"gotchas" in the DB Adaptor related code. =20

There will be some minor issues around DB's that don't support
autogenerated fields and idMethod=3Dnative, but they are getting
fewer. =20

OM Code Generation=20

IMHO, there are major functional options, minor functional=20
options, and some that probably should be deprecated.

The major options are ones that really effect the code=20
generations a great deal and have the most chance of generating
unusable code.  These are:

  torque.useManagers
  torque.generateBeans
  torque.objectIsCaching
  torque.enableJava5Features
  torque.complexObjectModel
  torque.addGetByNameMethod

The minor options are:

  torque.addSaveMethod
  torque.saveException
  torque.correctGetters

I'll probably start some controversy by suggesting that IMHO=20
the following options should be deprecated and the code=20
generated made non-optional in 4.0:

  torque.addGetByNameMethod =20
  torque.addSaveMethod
  torque.complexObjectModel (maybe not?)

Anyway, as to testing... if we drop the minor options from=20
the list or just slip them in as a minor variation of the
major ones.  We could run 64 tests with all variations, but
a lot of them would fail.

Two of the options are currently required for the test cases
to succeed.  These are:

  torque.complexObjectModel
  torque.addGetByNameMethod

If we drop these out and then it becomes a reasonable 16
combinations of the following:

  torque.useManagers
  torque.generateBeans
  torque.objectIsCaching
  torque.enableJava5Features

We probably can just run 10 if we just run enableJava5 against
a couple of variations of the the other 3, rather than all
variations.

So ideally, to up the odds that a release is good, there would=20
10-16 runs to test the OM code variations and 2 x the common
DBs.  The OM code variations could be wrapped in a small
Ant script (or shell script / batch file ) to make it easier
to run. =20

Thoughts, gapping holes in my logic (would be the first time..),
improvements, whatever...

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are =
confidential communication or may otherwise be privileged or =
confidential and are intended solely for the individual or entity to =
whom they are addressed.  If you are not the intended recipient you may =
not rely on the contents of this email or any attachments, and we ask =
that you  please not read, copy or retransmit this communication, but =
reply to the sender and destroy the email, its contents, and all copies =
thereof immediately.  Any unauthorized dissemination, distribution or =
copying of this communication is strictly prohibited.


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