I think that the class NetConnectionReply is a good one to investigate. From what I can see, there are a lot of coverage gaps in this class, at least according to http://dbtg.foundry.sun.com/derby/test/coverage/_files/3c.html
I agree that the protocol errors are hard to test for, so it's easier to look for other parts of the class that aren't covered very well. It's interesting that there appear to be large sections of this large and and complex class that aren't touched at all. For example, NetConnectionReply::parseCMDNSPRM() appears to be untouched: http://dbtg.foundry.sun.com/derby/test/coverage/_files/33a.html#e And that is a pretty large section of code that we aren't calling at all? I wonder if perhaps I'm reading the coverage reports incorrectly. But if not, and if, as Knut Anders suggested, there are some more opportunities to find entirely dead code that we don't need, that would be great, as the less code we have, the less we have to maintain. I think that substantial parts of the Derby client library were originally descended from a library that spoke to various DB2 server implementations, and I think that there is possibly a fair amount of the client code that was needed for the DB2 inter-operability, but is never used when a Derby client is speaking to a Derby server. So in this case, for example, can the Derby server ever return a CMDNSPRM message to the client? thanks, bryan
