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 Sat, 09 Jun 2012 19:40:22 GMT
On 06/06/2012 04:10 AM, Knut Anders Hatlen wrote:
> One strategy may be to pick one piece of code that lacks coverage,
> and find the corresponding code on the server which sends that kind of
> data to the client.

I think this is a good technique.

I tried your suggested technique, looking at the DSCSQLSTT code
point and how it was handled (lines 176-182 of NetStatementReply.java
are apparently not covered).

I got as far as determining that the client code would be executed,
if, on the server side, DRDAStatement::Prepare() should happen to
throw a SQLException.

I then spent some time trying to figure out possible ways to provoke
such an exception to be thrown.

I didn't find such a code path, but I *did* encounter a DRDA protocol
crash, which I was able to log as DERBY-5806.

Thus:
a) I think your suggested technique for trying to increase the coverage
is an excellent one, and
b) Even if it is challenging to provoke these new code paths to be
taken, simply attempting to cause them to occur can be a fruitful
way to find new bugs!

thanks,

bryan

Mime
View raw message