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
