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 Fri, 06 Jul 2012 07:15:05 GMT
Mohamed Nufail <nufail56@gmail.com> writes:

> Hi,
>
> I moved onto implementing some tests for the client.am package. I
> first tried to cover the LogicalPreparedStatement class. I'm still
> working on it and uploaded the current version on the following link.
> http://pastebin.com/w4JqSh5Z
>
> In writing the above test, I looked into the following tests which are
> similar and tried to follow them.
> - org.apache.derby.client.am.LogicalStatementEntityTest
> -
> org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest
> -
> org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest
>
> Most of the testParameterTypes() method is taken from
> PrepareStatementTest#testParameterTypes().

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)))));

> testUnsupportedParameterTypes() is supposed to invoke JDBC4 specific
> methods in LogicalPreparedStatement40. So it should be run only in JVM
> which supports it. How do I enforce this?

There's a helper method JDBC.vmSupportsJDBC4() that can be used to check
if JDBC 4 is supported on the JVM. You could either check it in the
suite() method and only add the test case if it's expected to succeed,
or you could check it at the start of the test case and return early if
it needs to be skipped.

Sometimes, though, the JDBC 4 test cases must be moved to a separate
class, since the test class may not even load on older JVMs if the test
uses classes/methods that don't exist on the older JVM.

> Moreover, to create a LogicalPreparedStatement, I've now used
> ClientPooledConnection and CachingLogicalConnection in the method
> createLogicalPreparedStatement(). But in LogicalStatementEntityTest,
> this is done straightly through StatementCacheInteractor. But those
> methods are package-private. So I had to use this methodology.

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.

> I would be including couple more tests to this and do some clean-up
> and hope to write a similar test to cover LogicalCallableStatement
> also. But I would like to get feedback on my current progress. I'd
> like to know if I'm going down the correct path.
>
> Regards,
> Nufail.

-- 
Knut Anders

Mime
View raw message