db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Reopened: (DERBY-1496) testSecMec needs many masters - should convert to junit
Date Thu, 29 Mar 2007 21:12:33 GMT
Myrna van Lunteren wrote:
> On 3/29/07, Daniel John Debrunner <djd@apache.org> wrote:
>> Myrna van Lunteren wrote:
>> > On 3/28/07, Daniel John Debrunner (JIRA) <jira@apache.org> wrote:
>> >>
>> >>     [
>> >> 
>> https://issues.apache.org/jira/browse/DERBY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

>>
>> >> ]
>> >>
>> >> Daniel John Debrunner reopened DERBY-1496:
>> >> ------------------------------------------
>> >>
>> >>
>> >> 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?
>> >>
>> > Possibly...
>> > It may be the extra time needed is because the database is reused for
>> > each security mechanism. I imagine that takes longer, so the server
>> > may be up, but the database not (yet).
>>
>> A different approach may be to use the client server decorator which
>> already handles this. Then each security mechanism would be a different
>> fixture run.
>>
>> Dan.
>>
>>
> Hm, the test already uses clientServerDecorator. Did I make a mistake
> there somewhere?

 From what I could tell the test has a single fixture that starts up 
(and shuts down) the network server several times, for each value of a 
system property. Thus within the fixture code exists to start and 
shutdown the server, which duplicates the code in client server 
decorator. So another way of writing the test would be to use existing 
decorators to set the system property and start and shutdown the server. 
Thus I think we wouldn't need a 120second wait for each network server 
start, the client server decorator already handles that. One of the 
issues with the old harness tests that we had many different ways to 
check to see if the server is already running, it would be nice to avoid 
that.

As an example the suite method could be something like:

  for (int i = 0; i < derby_drda_securityMechanisms.length; i++)
  {
     Test test = new 
NSSecurityMechanismTest("testNetworkServerSecurityMechanism", i);

     test = TestConfiguration.clientServerDecorator(test);

     test = new SystemPropertyTestSetup(test, 
"derby.drda.securityMechanism", derby_drda_securityMechanisms[i]);

     suite.addTest(test);
  }

That is a fixture becomes a single run of the network server against a 
single network server startup/shutdown cycle.

Dan.



Mime
View raw message