[
https://issues.apache.org/jira/browse/DERBY-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011067#comment-13011067
]
Myrna van Lunteren commented on DERBY-5084:
-------------------------------------------
Firstly, thank you for working on this issue.
I took a closer look at your patch, and I think the problem you're seeing - the
second run (probably the second one is the network server run, but the order
depends on the jvm) fails with 'connection made to existing database instead'
is because the sql script creates its own database using the connect statement
with ";create=true". Most tests don't test database creation, and can rely on
methods in TestConfiguration such as CleanDatabaseSetup or
singleUseDatabaseDecorator...But we cannot do that in this case.
Using TestConfiguration.singleUseDatabaseDecorator was a good attempt, but - as
you can see by reading the javadoc description of the method - it's creating
databases with a specific naming scheme.
CleanDatabaseSetup assumes it will create the database to be used and the name
will be 'wombat'.
I think I ran into these same problems before, and ended up creating a separate
teardown method in at least one instance, see
org.apache.derbyTesting.functionTests.tests.i18n.LocalizedAttributeScriptTest.java.
Note also that the .sql script for that test has a shutdown of the system to
ensure the database directories can be removed; ijConnName.sql will need
something similar.
Note finally, that as this test uses some hard-coded urls that only reflect
embedded, it would be pointless to run this with networkserver; it'll only
connect using the embedded driver but start network server for no reason.
Perhaps a similar test (.sql file) can be made to use network server urls and
run that through NetworkServerTestSetup, but I'd say that would be an
improvement beyond the scope of this JIRA.
Apart from the database creation and cleanup issues, I don't think the current
test is testing the same as the original one.
Although it certainly manages to create a database using the same (or similar)
URL, the original tests some ij specific properties which were set in the
_app.properties file. You've rolled those properties into the url in the
connect statement in the .sql file, which is not the same thing...
I think you will need to wrap the test in a SystemPropertyTestSetup of some
sort to set up those ij properties (which would unset them automatically
afterwards).
Finally, you should run the suite through the getIJConfig() method. This
ensures that the test only runs when ij is available in the classpath.
> convert ijConnName.sql to a ScriptTest junit test
> -------------------------------------------------
>
> Key: DERBY-5084
> URL: https://issues.apache.org/jira/browse/DERBY-5084
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Myrna van Lunteren
> Priority: Trivial
> Labels: derby_triage10_8
> Attachments: DERBY-5084-1.patch, DERBY-5084-2.patch,
> DERBY-5084.patch, ijConnName-1.out, ijConnName-1.tmp
>
>
> In DERBY-3089 it is mentioned that tools/ijConnName.sql should get converted
> to a junit test, probably using ScriptTest.
> Making a separate issue so that that issue can be closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
