db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From torque-...@db.apache.org
Subject [DB Torque Wiki] Updated: UnitTestingWithTorque
Date Mon, 17 May 2004 17:34:05 GMT
   Date: 2004-05-17T10:34:05
   Editor: 67.166.116.227 <>
   Wiki: DB Torque Wiki
   Page: UnitTestingWithTorque
   URL: http://wiki.apache.org/db-torque/UnitTestingWithTorque

   equal() experiences, random tuning

Change Log:

------------------------------------------------------------------------------
@@ -1,15 +1,15 @@
 Unit-testing with Torque can take two forms:
 
- * the DbUnit approach, which actually runs the SQL in a database and determines if the correct
records are returned;
+ * the DbUnit approach
  * testing the contents of the Criteria object
 
 == DbUnit Testing ==
 
-This is a straight-forward application of the DbUnit package.  It's easy but the runtime
costs add up, and a lot of the code needed for testing is specific to the table being tested.
+This is a straight-forward application of the DbUnit package.  Populate a test environment
in the database using DbUnit, run the code under test, determine if the correct records were
returned.  It's easy enough but the runtime costs add up, and (in my case) leads to development
of a fairly large body of code that does nothing but prepare datasets for testing.  The biggest
downside of this approach is that it tests Torque, and we'd like to assume that Torque works,
and test our instructions to Torque without testing Torque itself.  Perhaps the DbUnit tests
have a place as occasionally run validations of the schema, but even there I think it would
be better to deal with the schema file directly and assume that Torque does the right thing
with it.
 
 == Criteria Testing ==
 
-Unit-testing with the Criteria object is a little tricky but very fast at runtime.  The main
reason this page exists is because I've struggled with one simple fact about the Criteria
object: the predicate (OR, AND, IN, etc.) information is in a package-scoped class.  As a
result, my natural tendency to dig around in the Criteria object and find what I need has
been blocked.  Hmmmm, there must be another way.
+Unit-testing with the Criteria object satisfies the desire to test the instructions given
to Torque without testing Torque.  It is a little tricky but very fast at runtime.  I've struggled
with one simple fact about the Criteria object: the predicate (OR, AND, IN, etc.) information
is in a package-scoped class.  As a result, my natural tendency to dig around in the Criteria
object and find what I need has been blocked.  Hmmmm, there must be another way.
 
 Here are a variety of methods for testing the contents of the Criteria class:
 
@@ -28,8 +28,8 @@
 
 === Criteria.equal() ===
 
-Just stumbled on this today, haven't tried it yet.  Could be the elegant solution, if equal()
is written to ignore ordering issues.  Simply create the correct Criteria object, and check
if the Criteria object generated by the code under test is equal() to it.
+Could be the elegant solution, if equal() is written to ignore ordering issues.  Simply create
the correct Criteria object, and check if the Criteria object generated by the code under
test is equal() to it.  As of today (2004/05/17) I am experiencing mismatches between two
Criteria containing identical IN values for the same field, the difference being that one
was built from a List of Integer, and the other built from an array of int.  This could be
construed as a bug, but that's up to the class author.
 
 === Criteria.toString() ===
 
-Just another untried idea.
+Haven't looked at the code to see if there's any canonicalization being done, so that differently
entered, but identical, statements generate identical strings.

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