On 6/6/2012 4:10 AM, Knut Anders Hatlen wrote:
However, it looks like a lot of the code is handling errors, many of them protocol errors (which would only happen if there's a bug in the server or the client) or very unlikely errors (like NetResultSetReply.parseCloseError() which is only called if the server experienced an error in ResultSet.close()). It's very hard to test this code, and it might even require changes on the server to force it to generate errors while testing. It might be easier to start with the classes that implement the java.sql interfaces in the client.am package, as most of their methods could be called directly from the test. I see for example that classes like LogicalPreparedStatement and LogicalCallableStatement have very little coverage.
For protocol errors usually these are only exercised with the protocol tests. (By adding them to protocol.tests in the derbynet package and running derbynet.ProtocolTest. That said, that process can be somewhat painful and I don't think they are high value test cases as really although the client needs to handle them, they should not happen in normal operation.
I think for a summer project it is good to focus on method vs block coverage and agree it is a higher priority and easier to get the basic sql interface implementation methods covered on the client.
Kathey
