[ http://issues.apache.org/jira/browse/DERBY-1496?page=comments#action_12423966 ] Daniel John Debrunner commented on DERBY-1496: ----------------------------------------------
Just looking at datasourcepermissions I would say you are generally on the right track, but when I run the test using JUnit directly it fails for me. I think starting by running it in JUnit alone is the best approach, forget the test harness and focus on JUnit. Your suite method (correctly) creates four test cases, or as JUnit says "fixtures". Each fixture will run the setUp and tearDown methods of the class, thus you will run them four times. I don't know if that's what you meant or not. If you want it to be once per-suite then you create a decorator. Think about the normal mode for Junit tests to be that Derby is already running with a database created and the tests are just run against that database. We need to have some decorators that ensure the database is clean, but you can work without them for now (just remove the database each time you run, that's what the test harness will do when you finally plug into that). I say this because you code is shutting down Derby and re-booting it, I'm not sure why, it may be inherited from the old test and it may be required, but it would be good to keep the normal mode in mind. Also look at the BaseJDBCTest class and the TestConfiguraiton class, if we can factor out DriverManager calls then we also run these tests on J2ME. One way to stage this would be to create a new JUnit test class based upon datasourcepermissions .java rather than having to convert both tests at the same time, then once your new class is working move onto the _net approach. One more thing that jumps oput at me is the setting of the database properties, that's code that could be common. I just created a SystemPropertyTestSetup class that sets system properties based upon a passed in set, setting database properties could be handled the same way, rather than have each test do it itself. > 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
