You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Deepa Remesh (JIRA)" <de...@db.apache.org> on 2005/12/08 00:17:08 UTC
[jira] Commented: (DERBY-706) Improve testing and increase code coverage for Network Server classes
[ http://issues.apache.org/jira/browse/DERBY-706?page=comments#action_12359665 ]
Deepa Remesh commented on DERBY-706:
------------------------------------
I have attached a second patch 'derby-706_2.diff' which adds some more tests and re-arranges/removes some internal methods. Details of patch are:
* DDMWriter: Removes min method because Math.min is used. Use doesRequestContainData() method.
* DDMReader: Use readCodePoint() method
* DRDAConnThread: QRYOPTVAL codepoint is not part of DRDA spec. parseCcsidSBC was giving NPE.
* CodePointNameTable: Add codepoints to be used in protocol.tests
* protocol.tests: Added tests to cover methods which were not tested before.
* Session, DRDAStatement, Database, DRDAProtocolException: Remove some methods which are not needed. The same can be done using other methods.
* TestProto: Use lookup method.
* testProtocol: Added "derby.drda.traceAll=true" to derby.properties file to test methods in DssTrace
* testProperties: Added test for trace off command. Added "derby.drda.traceAll=true" to derby.properties file to test memcheck.
* runtimeinfo: Rearranged test because the output was not predictable on different jvms/machines.
Ran derbyall with Sun JDK 1.4.2 on WinXP. No failures. Please review/commit this patch.
Kathey, I looked into your question:
//this looks highly suspect. Why does timeSlice setSoTimeout?
if (timeSlice != 0)
clientSocket.setSoTimeout(timeSlice);
>From what I understand, setSoTimeout socket option is used so that a thread waits only for the time specified. Otherwise for blocking operations, a thread can wait indefinitely. In case of network server, it can wait indefinitely without considering value specified in timeslice property. I have not included the test for these in this patch.
I have couple of questions:
1. In one case where agentError is thrown (DRDAConnThread#parseNOCMorNOCS), it seems to me that a syntax error should be thrown here. For agentErrors, no code point is sent back to the client. In DDM manual, I saw AGNPRMRM is used for severe agent errors. Is there something else which can be sent back for non-severe errors?
2. QRYINSID is checked in CNTQRY and CLSQRY but it is not being used. Should this be used?
I would appreciate if someone can provide answers for above. Thanks.
> Improve testing and increase code coverage for Network Server classes
> ---------------------------------------------------------------------
>
> Key: DERBY-706
> URL: http://issues.apache.org/jira/browse/DERBY-706
> Project: Derby
> Type: Improvement
> Components: Test
> Versions: 10.2.0.0
> Reporter: Deepa Remesh
> Assignee: Deepa Remesh
> Priority: Minor
> Attachments: derby-706.diff, derby-706.status, derby-706_2.diff, derby-706_2.status
>
> Improve testing of network server by increasing tests to cover 100% of the classes and increase the method level coverage. The current code coverage(class/method) for network server based on svn revision 208786 are:
> org.apache.derby.drda.NetworkServercontrol.java - 100/72
> org.apache.derby.impl.drda - 97/78
> Details of code coverage from EMMA tool are available from Derby Wiki. Links are:
> http://wiki.apache.org/db-derby/CodeCoverage
> http://people.apache.org/~fuzzylogic/codecoverage/208786/_files/c5.html
> http://people.apache.org/~fuzzylogic/codecoverage/208786/_files/25.html
--
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