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.