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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
