[ http://issues.apache.org/jira/browse/DERBY-1496?page=all ]
Myrna van Lunteren updated DERBY-1496:
--------------------------------------
Attachment: DERBY-1496_tmp_072206.stat
DERBY-1496_tmp_072206.diff
This is my first real foray into the realm of junit tests...
And I got mixed results, so far.
I would really appreciate it if someone interested in converting tests to
junit, or someone who knows how junit tests are supposed to look could review
what I've done so far and give me feedback...
The attached patch - DERBY-1496_tmp_072206.* - doesn't modify testSecMec.java
at all...
Because testSecMec.java extends dataSourcePermissions_net.java which extends
dataSourcePermissions.java and I'm currently stuck on converting the
dataSourcePermissions_net test.
This is what I did:
I started converting jdbcapi/dataSourcePermissions.java which seemed to go well
enough.
My first step was to just run the test as a junit test, which meant:
- remove main method
- add setUp method
- add constructor for taking test name
- extend from BaseJDBCTestCase
- replace cleanUp with tearDown
- add test methods that start with 'test' for the actual string
- replace chatty System.out.printlns with println
Then I ran this test with
java -Dverbose=true -Dkeepfiles=true -Djvmflags=-Dderby.test.debug=true
org.apache.derbyTesting.functionTests.harness.RunTest
jdbcapi/dataSourcePermissions.junit
The resulting .out was hard to deal with using my vdiff32 on windows, so I
went ahead and added DEBUG and .DEBUG to Sed.java to be filtered during my
conversion
exercises.
Now the resulting diff was easy to oversee.
The next step was to convert all the checkConnections to assertTrue.
Reran the test, then reran withouth the derby.test.debug and got rid of the
.out.
As an afterthought, I created a testSuite method.
So far so good, much encouraged, I went on to work on
dataSourcePermissions_net.java.
And that's as far as I got.
Problem 1:
One of the aspects is that I had to add grant a number of permissions that are
granted to various jars already, but apparently had to be added again - maybe
to junit?
Problem 2:
There seemed to be no efficient way to get a simple connection to networkserver
using a different port than the default 1527. I was quite surprised really that
the original test was able to do this with ij.startJBMS().
I contacted Kathey on the IRC and she said the 20000 was put in at a time that
there was no startServer=false property, so it could go back to 1527 now.
So that's what the test is doing currently, but I would like to make a way to
get connections to a different port.
Problem 3:
The current test executes setUp and tearDown a number of times. Each time it
also calls the super methods. I think I did this wrong, but I am not clear on
how to do it instead.
Probably some of the setup needs to go into a decorator. I'll experiment with
that next.
Problem 4:
For some reason, I currently only get output for the
testDriverManagerPermissions subtest.
It's very strange, in the (eclipse) debugger I can see that junit apparently
does recognize that it needs to do something with these tests, but all it ends
up doing are setUps and tearDowns and shutdowns and starts. No doubt because of
me call supers, but I still don't see why it's not running the tests.
So, I'll keep muddling on, but I thought I'd log what I've done so far.
Obviously, this patch is not suitable for commit.
> testSecMec fails with jcc2.8 with 131 jvms
> ------------------------------------------
>
> Key: DERBY-1496
> URL: http://issues.apache.org/jira/browse/DERBY-1496
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.2.0.0
> Reporter: Sunitha Kambhampati
> Assigned To: Myrna van Lunteren
> Priority: Minor
> Attachments: DERBY-1496_tmp_072206.diff, DERBY-1496_tmp_072206.stat
>
>
> derbynet/testSecMec.java fails with jcc2.8 with 131 vms. I have checked the
> diff and it is a master update with difference in the exception, message
> string.
> diff snippet:
> 8 del
> < T5:
> jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9;
> - EXCEPTION java.security.InvalidAlgorithmParameterException is caught when
> initializing EncryptionManager 'Prime size must be multiple of 64, and can
> only range from 512 to 1024 (inclusive)'
> 8a8
> > T5:
> > jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9;
> > - EXCEPTION java.security.NoSuchAlgorithmException is caught when
> > initializing EncryptionManager 'DH KeyPairGenerator not available'
> 14 del
> ----------------
> There is difference in the exception message and will require lot of jvm
> specific master files which can become difficult to maintain. Myrna
> suggested that this might be a good test to convert to junit.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
