db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohamed Nufail <nufai...@gmail.com>
Subject Re: Code coverage for client.net package
Date Sat, 07 Jul 2012 17:28:17 GMT

On Fri, Jul 6, 2012 at 12:45 PM, Knut Anders Hatlen

> Instead of copying code from PrepareStatementTest, I'm wondering if we
> could rather reuse the code directly by tweaking PrepareStatementTest's
> suite() method to run the test cases with a decorator that makes them
> use pooled connections. Something along the lines of:
> suite.addTest(TestConfiguration.clientServerDecorator(
>     TestConfiguration.connectionCPDecorator(new CleanDatabaseTestSetup(
>         new TestSuite(PrepareStatementTest.class)))));
> Thank you. That seems like a better way of doing it. I tested it with
PrepareStatementTest and LogicalPreparedStatement does get covered.

I also tried it with jdbc4.PreparedStatementTest and
jdbc4.CallableStatementTest. Again everything is fine with coverage of
LogicalPreparedStatement. But LogicalPreparedStatement40 and
LogicalCallableStatement classes doesn't seem to get properly covered. Only
few methods in those classes are shown as covered in emma. But for some
methods shown as not covered, the corresponding methods in the physical
statement classes are showed as covered.
I think when pooled connection is used it should create logical statements
and under JDBC4 it should create xxxx40 statements. So all calls should go
through those classes. Is there a reason for coverage report showing no
coverage for some methods, which are called in the test classes and whose
physical statement methods are also covered?

> If they could be created with some of the existing decorators, I think
> that would be preferable. The advantage of using the decorators is that
> the new tests won't be limited to running on LogicalStatements and could
> test all our classes that implement java.sql.Statement, which gives us
> some additional testing. Also, if we use the same test code for all
> kinds of statements, we can detect if the different statement
> implementations behave differently, which we try to avoid.
> --
> Knut Anders


Mohamed Nufail
Department of Computer Science & Engineering,
University of Moratuwa.
Blog: http://www.nufailm.blogspot.com/

View raw message