db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: Some thoughts on new version testing.
Date Thu, 16 Nov 2006 09:18:42 GMT
The set of 10-16 tests to be run per db sounds fine to me as a release
test. If you want to create an ant script for this, this would be great.
Can the ant script go into the maven.xml so we do not have additional files
floating round ?

          Thomas

"Greg Monroe" <Greg.Monroe@DukeCE.com> schrieb am 15.11.2006 22:16:47:

> 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
>


---------------------------------------------------------------------
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