db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: Some thoughts on new version testing.
Date Wed, 15 Nov 2006 21:16:47 GMT
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 
     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 
(because we'd know already if the defaults didn't work)
to these options and verifing that they compile and pass 
the test (mostly just compile).  

There is also an secondary test for them in the fact that 
some test case code references the OM classes and won't 
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 
run will "validate" them.

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

  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 
standard tests against the DB similar to:

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

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

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

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

OM Code Generation 

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

The major options are ones that really effect the code 
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 
the following options should be deprecated and the code 
generated made non-optional in 4.0:

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

Anyway, as to testing... if we drop the minor options from 
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 
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.  

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


Mime
View raw message