db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2467) Convert lang/updateCursor.java to JUnit
Date Wed, 28 Mar 2007 10:12:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484795

Andrew McIntyre commented on DERBY-2467:

Ugo> I think that the issue is almost resolved. The only thing that remains to do is to
read in some way the property file linked with the old test. Unfortunately, I haven't found
no example of how to accomplish this task. 

Tests that are converted to JUnit should specify their necessary system properties programmatically,
and not rely on external files. For system properties, there is a SystemPropertyTestSetup
class, which provides a JUnit decorator for specifying system properties. 

Good examples of using this decorator are in tests/derbynet/ClientSideSystemPropertiesTest.suite()
and tests/jdbcapi/AuthenticationTest.setBaseProps().

A couple of other comments:

- Instead of setting up the database in a setUp() method and then having your test be responsible
for cleaning the database at teardown(), take a look at using the CleanDatabaseTestSetup decorator.
A good example is in tests/lang/GroupByExpression test, but there are many other examples.
Using this test decorator requires anonymous overloading of the CleanDatabaseTestSetup's decorateSQL
method, but doing so will allow you to remove a lot of code related to setting up and cleaning
out the database, which helps makes the test code in the test stand out from the 'background
noise' of the setup operations. Refer to other tests which make use of CleanDatabaseTestSetup
to get a feel for how it is used.

- Using the above may require rethinking how the data in the table is filled. At any rate,
the process of assembling the insert statement that inserts the 'largeString' into the test
tables can probably be simplified. As it is now, there is a lot of object creation and method
calling going on behind the scenes of the statement that assembles the String (and thus StringBuffer/StringBuilder)
for inserting the 'largestring' and various values of i into t1. Using a PreparedStatement
here and setting its parameters for each iteration of the for loop would have noticable benefits,
including reuse of the compiled PreparedStatement and avoiding unnecessary creation of String
objects in that large string concatenation that occurs for each iteration of the for loop.

- Because BaseJDBCTestCase extends from junit.framework.TestCase, it is usually not necessary
to explicitly add the Assert classname to assert methods when using them in tests. e.g.:


can usually be called as:


Thanks for taking the time to convert this test! I'll take a closer look at it tomorrow and
let you know if I have any further comments.

> Convert lang/updateCursor.java to JUnit
> ---------------------------------------
>                 Key: DERBY-2467
>                 URL: https://issues.apache.org/jira/browse/DERBY-2467
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>    Affects Versions:
>            Reporter: Ugo Matrangolo
>         Assigned To: Ugo Matrangolo
>            Priority: Minor
>             Fix For:
>         Attachments: DERBY-2467_diff_03_27.txt, DERBY-2467_stat_03_27.txt
> Convert lang/updateCursor.java to JUnit

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message