db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: Code coverage for client.net package
Date Wed, 20 Jun 2012 14:24:32 GMT
On 06/18/2012 11:22 AM, Katherine Marsden wrote:
> I believe with ProtocolTest the client is not invoked at all but rather replaces the
client, so it can only be used to help
> cover server side code.

Oh! Good catch, Kathey! Thanks for saving us from heading down a dead end.


 > I suppose some similar test framework.could be written to throw unexpected protocol
at the client to exercise some of the client
 > code to detect a misbehaved server but I don't think it is worth it. In addition this
particular case is geared to detecting the
 > client gives a proper response to to the server's proper response to the client misbehaving,
so I think it is just one of those
 > cases that ok to leave uncovered.
 >
 > I would prefer to see you focus on code paths for positive cases than extremely remote
negative protocol errors.
 >
 > So if looking at NetConnectionReply, I would say focus first on methods that are not
covered at all and do not sound protocol
 > error related for example, in that file I see parseRDBATHRM which I would think we would
cover for an authentication failure and
 > something called verifyConnectReply(). Is that called anywhere and what should it do?
You might want to look at a higher level
 > am.Connection and net.Connection. What's not covered there?

Excellent ideas.

+1, and thanks for the suggestions!

bryan

Mime
View raw message