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 Thu, 07 Jun 2012 02:40:00 GMT
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

Mime
View raw message