Derby
  1. Derby
  2. DERBY-1496

testSecMec needs many masters - should convert to junit

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.3.1.4
    • Component/s: Test
    • Labels:
      None

      Description

      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.

      1. DERBY-1496_tmp_072206.stat
        0.6 kB
        Myrna van Lunteren
      2. DERBY-1496_tmp_072206.diff
        47 kB
        Myrna van Lunteren
      3. DERBY-1496_20070321.diff
        38 kB
        Myrna van Lunteren
      4. DERBY-1496_20070306.stat
        1 kB
        Myrna van Lunteren
      5. DERBY-1496_20070306.diff
        125 kB
        Myrna van Lunteren
      6. authtest_clear_prop.txt
        4 kB
        Daniel John Debrunner

        Activity

        Sunitha Kambhampati created issue -
        Myrna van Lunteren made changes -
        Field Original Value New Value
        Assignee Myrna van Lunteren [ myrna ]
        Hide
        Myrna van Lunteren added a comment -

        I want to try converting this one. I'll report on the experience when done.

        Show
        Myrna van Lunteren added a comment - I want to try converting this one. I'll report on the experience when done.
        Hide
        Myrna van Lunteren added a comment -

        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.

        Show
        Myrna van Lunteren added a comment - 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.
        Myrna van Lunteren made changes -
        Attachment DERBY-1496_tmp_072206.diff [ 12337352 ]
        Attachment DERBY-1496_tmp_072206.stat [ 12337351 ]
        Hide
        Myrna van Lunteren added a comment -

        I'm flagging patch available to solicit some review from junit-knowledgeable folks...Am I on the right track?

        Show
        Myrna van Lunteren added a comment - I'm flagging patch available to solicit some review from junit-knowledgeable folks...Am I on the right track?
        Myrna van Lunteren made changes -
        Derby Info [Patch Available]
        Hide
        Daniel John Debrunner added a comment -

        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.

        Show
        Daniel John Debrunner added a comment - 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.
        Hide
        Daniel John Debrunner added a comment -

        I think issue with the permissions is that calls to privilege actions are not in privlege blocks.
        WIth the test harness that was ok because it was granted the permission and was at the top of the calling stack.
        With JUnit, the JUnit code is at the top of the stack and so either it needs to be granted the permissions, or ther cleaner
        approach is to have the calls in a privilege block, e.g. see BaseTestCase.setSystemProperty.

        Show
        Daniel John Debrunner added a comment - I think issue with the permissions is that calls to privilege actions are not in privlege blocks. WIth the test harness that was ok because it was granted the permission and was at the top of the calling stack. With JUnit, the JUnit code is at the top of the stack and so either it needs to be granted the permissions, or ther cleaner approach is to have the calls in a privilege block, e.g. see BaseTestCase.setSystemProperty.
        Hide
        Myrna van Lunteren added a comment -

        taking of patch available flag - thx dan for your comments. I did think about making a test for dataSourcePermissions first, but as the point of this exercise is really to convert testSecMec and dataSourcePermissions is ok as is in java world, I decided I'd tackle all 3 chained tests together...I may still change my mind but will give this another go.

        Show
        Myrna van Lunteren added a comment - taking of patch available flag - thx dan for your comments. I did think about making a test for dataSourcePermissions first, but as the point of this exercise is really to convert testSecMec and dataSourcePermissions is ok as is in java world, I decided I'd tackle all 3 chained tests together...I may still change my mind but will give this another go.
        Myrna van Lunteren made changes -
        Derby Info [Patch Available]
        Hide
        Myrna van Lunteren added a comment -

        adjusting the summary. Running with ibm131 is not interesting for trunk.

        Show
        Myrna van Lunteren added a comment - adjusting the summary. Running with ibm131 is not interesting for trunk.
        Myrna van Lunteren made changes -
        Summary testSecMec fails with jcc2.8 with 131 jvms testSecMec needs many masters - should convert to junit
        Hide
        Myrna van Lunteren added a comment -

        After an apparent inactivity of many moons, I'm attaching a preliminary step for a second attempt at converting testSecMed.java.
        While I'm battling testSecMec itself, the attached patch is an attempt at combining relevant parts of users.sql, users2.sql, secureUsers.sql and secureUsers1.sql with dataSourcePermissions/_net.java, so that these 6 tests can be removed.

        In addition to creating a number of test classes extending from the basic datasource testing class AuthenticationTest.java, the patch also contains changes to checkDataSource.java. These changes are there because of datasource functionality (almost) tested in dataSourcePermissions_net.java, but which have no authentication aspect. If decided they'd fit better in checkDataSource.
        The new testing in checkDataSource could be done more efficiently, but I'm not getting into that now - maybe that can be addressed when someone converts it.

        Finally the patch modifies DropDatabaseSetup.java to not use the JDBCDataSource.shutdownDatabase(ds), which results in an attempt to use a ds.setter method not supprted with DerbyNetClient (see also DERBY-2296)

        This patch is intended for review only - I have not tested the tests in a suite.

        Show
        Myrna van Lunteren added a comment - After an apparent inactivity of many moons, I'm attaching a preliminary step for a second attempt at converting testSecMed.java. While I'm battling testSecMec itself, the attached patch is an attempt at combining relevant parts of users.sql, users2.sql, secureUsers.sql and secureUsers1.sql with dataSourcePermissions/_net.java, so that these 6 tests can be removed. In addition to creating a number of test classes extending from the basic datasource testing class AuthenticationTest.java, the patch also contains changes to checkDataSource.java. These changes are there because of datasource functionality (almost) tested in dataSourcePermissions_net.java, but which have no authentication aspect. If decided they'd fit better in checkDataSource. The new testing in checkDataSource could be done more efficiently, but I'm not getting into that now - maybe that can be addressed when someone converts it. Finally the patch modifies DropDatabaseSetup.java to not use the JDBCDataSource.shutdownDatabase(ds), which results in an attempt to use a ds.setter method not supprted with DerbyNetClient (see also DERBY-2296 ) This patch is intended for review only - I have not tested the tests in a suite.
        Myrna van Lunteren made changes -
        Attachment DERBY-1496_20070306.diff [ 12352809 ]
        Attachment DERBY-1496_20070306.stat [ 12352808 ]
        Hide
        Daniel John Debrunner added a comment -

        > Finally the patch modifies DropDatabaseSetup.java to not use the JDBCDataSource.shutdownDatabase(ds), which results in an attempt to use a ds.setter method not supprted with DerbyNetClient (see also DERBY-2296)

        Does that mean the DropDatabaaseSetup no longer shuts down the database before dropping it?

        An alternate solution would be to modify JDBCDataSource.shutdownDatabase(ds) so that it works with the client data source.

        Show
        Daniel John Debrunner added a comment - > Finally the patch modifies DropDatabaseSetup.java to not use the JDBCDataSource.shutdownDatabase(ds), which results in an attempt to use a ds.setter method not supprted with DerbyNetClient (see also DERBY-2296 ) Does that mean the DropDatabaaseSetup no longer shuts down the database before dropping it? An alternate solution would be to modify JDBCDataSource.shutdownDatabase(ds) so that it works with the client data source.
        Hide
        Daniel John Debrunner added a comment -

        AuthenticationTest has several methods with names that include WOUP:

        assertShutdownWOUPFail

        from the name I can't figure out what the method is mean to be asserting, what's a WOUP, how do you shut it down?
        Since the methods also have no java doc comments I can't figure it out that way either

        Show
        Daniel John Debrunner added a comment - AuthenticationTest has several methods with names that include WOUP: assertShutdownWOUPFail from the name I can't figure out what the method is mean to be asserting, what's a WOUP, how do you shut it down? Since the methods also have no java doc comments I can't figure it out that way either
        Hide
        Myrna van Lunteren added a comment -

        Thx for looking at the test.
        WOUP stands for WithOutUser/Password. The difference is in the getConnection - it's getConnection() (getConnection(url) for DriverMgrAuthentication) vs. getConnection(user, password). It's only used in a couple of places, but I thought I'd throw it in.

        I floundered looking for a better name. Or would appropriate comments suffice? Or maybe it's nonsense to have it in the test in the first place...

        Show
        Myrna van Lunteren added a comment - Thx for looking at the test. WOUP stands for WithOutUser/Password. The difference is in the getConnection - it's getConnection() (getConnection(url) for DriverMgrAuthentication) vs. getConnection(user, password). It's only used in a couple of places, but I thought I'd throw it in. I floundered looking for a better name. Or would appropriate comments suffice? Or maybe it's nonsense to have it in the test in the first place...
        Hide
        Daniel John Debrunner added a comment -

        Minor patch that adds a clear java bean property method to JDBCDataSource and thus allows AuthenticationTest to use JDBCDataSource to manufacture data sources rather than implementing the logic itself.
        The existing logic means that the datasources created would not have the correct configuration such as port number.
        Only one method has been updated in AuthenticationTest, though others could be probably changed as well.

        Show
        Daniel John Debrunner added a comment - Minor patch that adds a clear java bean property method to JDBCDataSource and thus allows AuthenticationTest to use JDBCDataSource to manufacture data sources rather than implementing the logic itself. The existing logic means that the datasources created would not have the correct configuration such as port number. Only one method has been updated in AuthenticationTest, though others could be probably changed as well.
        Daniel John Debrunner made changes -
        Attachment authtest_clear_prop.txt [ 12353410 ]
        Hide
        Daniel John Debrunner added a comment -

        WOUP is fine with comments, makes sense then.

        btw AuthenticationTest passes with the patch I posted.

        Show
        Daniel John Debrunner added a comment - WOUP is fine with comments, makes sense then. btw AuthenticationTest passes with the patch I posted.
        Hide
        Daniel John Debrunner added a comment -

        I'm a little confused on AuthenticationTest.assertSystemShutdownFail

        The method name would indicate that it's asserting that an attempt to shutdown the system should fail,
        but the code is perfoming a database shutdown. There's some comment about not using the database name in
        the comment to the method causes some problems, but I'm not sure having the code perform a different action is the correct solution.
        I'd also assumed that to have a DataSource connect to the system a null databaseName would be used, but this test uses a zero-length
        database name. No idea which is correct or if it's documented one-way or another.

        Show
        Daniel John Debrunner added a comment - I'm a little confused on AuthenticationTest.assertSystemShutdownFail The method name would indicate that it's asserting that an attempt to shutdown the system should fail, but the code is perfoming a database shutdown. There's some comment about not using the database name in the comment to the method causes some problems, but I'm not sure having the code perform a different action is the correct solution. I'd also assumed that to have a DataSource connect to the system a null databaseName would be used, but this test uses a zero-length database name. No idea which is correct or if it's documented one-way or another.
        Hide
        Myrna van Lunteren added a comment -

        That section of the test was intended to test whether a system shutdown with incorrect user/password would get refused, however, I got successful shutdowns (XJ015) instead of checks for user/password.
        It's likely that in my confusion and wish to move on I messed this up.

        Show
        Myrna van Lunteren added a comment - That section of the test was intended to test whether a system shutdown with incorrect user/password would get refused, however, I got successful shutdowns (XJ015) instead of checks for user/password. It's likely that in my confusion and wish to move on I messed this up.
        Hide
        Myrna van Lunteren added a comment -

        attaching a patch that does the following:

        JDBCDataSource.java:

        • uses ds.setConnectionAttributes rather than ds.setShutDownDatabase().
          The test DriverMgrAuthenticationTest ran into failures on tearDown in clientServer. I left the old mechanism commented out, with comments...I know normally we'd rely on the svn logs, but I thought in this particular case it might
          be helpful to have the alternative approach in the method.

        NSSecurityMechanismTest:

        • remove the system property setting in tearDown()
        • test now sleeps a bit longer - on my system I was still getting 08001
          errors.
        • resolve a javadoc problem

        AuthenticationTest.java

        • suite() methods uses SystemPropertySetup in addition to DatabasePropertySetup.
        • suite() and baseSuite() methods are streamlined.
        • system level property removed via tearDown method.
        • (more) system shutdown testing done in a separate test case
        • system shutdown calls are fixed to actually attempt to shutdown the system (my previous problems with getting this to work properly were because I had only set the requireAuthentication to true at databaselevel.)
        • added more comments to some of the methods

        DriverMgrAuthenticationTest.java, PoolDSAuthenticationTest.java, XADSAuthenticationTest.java:

        • adjusted suite, baseSuite, and systemshutdown methods to match AuthenticationTest changes.

        jdbcapi/_Suite.java:

        • added 4 tests

        derbynet/_Suite.java:

        • added NSSecurityMechanismTest

        suites.All was successful with jdk14.

        I will commit this.

        Show
        Myrna van Lunteren added a comment - attaching a patch that does the following: JDBCDataSource.java: uses ds.setConnectionAttributes rather than ds.setShutDownDatabase(). The test DriverMgrAuthenticationTest ran into failures on tearDown in clientServer. I left the old mechanism commented out, with comments...I know normally we'd rely on the svn logs, but I thought in this particular case it might be helpful to have the alternative approach in the method. NSSecurityMechanismTest: remove the system property setting in tearDown() test now sleeps a bit longer - on my system I was still getting 08001 errors. resolve a javadoc problem AuthenticationTest.java suite() methods uses SystemPropertySetup in addition to DatabasePropertySetup. suite() and baseSuite() methods are streamlined. system level property removed via tearDown method. (more) system shutdown testing done in a separate test case system shutdown calls are fixed to actually attempt to shutdown the system (my previous problems with getting this to work properly were because I had only set the requireAuthentication to true at databaselevel.) added more comments to some of the methods DriverMgrAuthenticationTest.java, PoolDSAuthenticationTest.java, XADSAuthenticationTest.java: adjusted suite, baseSuite, and systemshutdown methods to match AuthenticationTest changes. jdbcapi/_Suite.java: added 4 tests derbynet/_Suite.java: added NSSecurityMechanismTest suites.All was successful with jdk14. I will commit this.
        Myrna van Lunteren made changes -
        Attachment DERBY-1496_20070321.diff [ 12353910 ]
        Hide
        Myrna van Lunteren added a comment -

        testSecMec.java was converted to junit test NSSecurityMechanimsTest with revisions 517483, 518978, 521055 & removed it (and related tests) with revision 522923.

        Show
        Myrna van Lunteren added a comment - testSecMec.java was converted to junit test NSSecurityMechanimsTest with revisions 517483, 518978, 521055 & removed it (and related tests) with revision 522923.
        Myrna van Lunteren made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 10.3.0.0 [ 12310800 ]
        Resolution Fixed [ 1 ]
        Hide
        Daniel John Debrunner added a comment -

        NSSecurityMechanismTest has this TODO in it:

        // TODO: sleep ridiculously long, otherwise getting 08001 errors
        // even when the server is up.
        Thread.sleep(120000);

        That sleep in executed a number of times, slowing the test runs down.
        If the server is up and running and giving errors, would that be a bug?

        Show
        Daniel John Debrunner added a comment - NSSecurityMechanismTest has this TODO in it: // TODO: sleep ridiculously long, otherwise getting 08001 errors // even when the server is up. Thread.sleep(120000); That sleep in executed a number of times, slowing the test runs down. If the server is up and running and giving errors, would that be a bug?
        Daniel John Debrunner made changes -
        Status Closed [ 6 ] Reopened [ 4 ]
        Resolution Fixed [ 1 ]
        Hide
        Myrna van Lunteren added a comment -

        Dan had suggested on the list, that this test be rewritten to use the testSetup mechanism to start and shutdown the server.
        I have attempted this approach but it's not as appropriate with this particular test - starting the server (with each security mechanism, invalid, or not) is part of the test.
        Also, once the server is started with a particular mechanism, connections need to specify that mechanim or fail - and so teardown fails.
        Finally, for each security mechanism, the expected values of each check is different.
        In the end, the test got really, really complicated and messy,

        I then attempted to create new databases for each security mechanism, but that also got very messy.

        In the end the solution was simple: shutdown the database in all cases (already happened for 2 of the security mechanism settings). before shutting down the server. Then, no wait was needed before attempting connections.

        So, after revision 533889, the NSSecurityMechanismTest should run a bit faster.

        Show
        Myrna van Lunteren added a comment - Dan had suggested on the list, that this test be rewritten to use the testSetup mechanism to start and shutdown the server. I have attempted this approach but it's not as appropriate with this particular test - starting the server (with each security mechanism, invalid, or not) is part of the test. Also, once the server is started with a particular mechanism, connections need to specify that mechanim or fail - and so teardown fails. Finally, for each security mechanism, the expected values of each check is different. In the end, the test got really, really complicated and messy, I then attempted to create new databases for each security mechanism, but that also got very messy. In the end the solution was simple: shutdown the database in all cases (already happened for 2 of the security mechanism settings). before shutting down the server. Then, no wait was needed before attempting connections. So, after revision 533889, the NSSecurityMechanismTest should run a bit faster.
        Hide
        Myrna van Lunteren added a comment -

        Although I don't see the entire suites.All run any faster, I think the obvious thing that could be improved in this test - removing the hardcoded sleeps - has been take care of.

        Show
        Myrna van Lunteren added a comment - Although I don't see the entire suites.All run any faster, I think the obvious thing that could be improved in this test - removing the hardcoded sleeps - has been take care of.
        Myrna van Lunteren made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Resolved [ 5 ]
        Myrna van Lunteren made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Gavin made changes -
        Workflow jira [ 12375179 ] Default workflow, editable Closed status [ 12797189 ]

          People

          • Assignee:
            Myrna van Lunteren
            Reporter:
            Sunitha Kambhampati
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development