db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Code coverage for client.net package
Date Tue, 22 May 2012 14:51:32 GMT
Bryan Pendleton <bpendleton.derby@gmail.com> writes:

>> First I will focus on the client.net <http://client.net> package. In the schedule
I mentioned that I would be looking into the
>> InputStreamUtil and DynamicByteArrayOutputStream classes first, because I thought
they would be easy to tackle with initially
>> and those two classes have the least coverage in that package according to emma reports.
> This sounds like a fine approach.
> I wonder: is it possible that we have existing tests that cover
> many of these classes, but are not being run because we currently
> run those tests only in the embedded configuration, and not
> in the network client configuration?

Those two classes have been copied from the engine code over to the
client, but the client uses only a small part of the functionality they
provide (in Request.writeUDT()).

I'm wondering if it would be more reasonable just to remove the two
classes and make writeUDT() use either java.io.ByteArrayOutputStream or
EncodedInputStream.PublicBufferOutputStream instead. The latter class
already is in the client.net package, but it would probably be a good
idea to make it a stand-alone class and not an inner class if we want to
reuse it in the Request class.

That would reduce the code size and increase the percentage covered.
Sounds like a win-win! :)

> Or, related, is it possible that our current Emma configuration
> is such that we are only measuring one side of the client-server
> pair in a test run?

I think it's measuring both sides. Most of the client/server tests run
with the client and the server in the same JVM process, so at least
those tests should be covered, and I think the test framework also
propagates the EMMA flags to spawned processes.

> Perhaps someone who has worked through the details of the
> Emma configuration for our test runs can make an educated guess
> about whether either of these questions are worth pursuing?
> thanks,
> bryan

Knut Anders

View raw message