Re: Code coverage for client.net package

[Mohamed Nufail <nu...@gmail.com>]

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().

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?

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.

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.

-- 

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

Re: LogicalPreparedStatement40 code coverage

[Mohamed Nufail <nu...@gmail.com>]

Hi,

I created a JIRA issue at https://issues.apache.org/jira/browse/DERBY-5851.
It contains details on how to reproduce this behaviour.

Thank you.
Nufail.

On Sun, Jul 8, 2012 at 9:33 PM, Bryan Pendleton
<bp...@gmail.com>wrote:

>  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?
>>
>
> Three possibilities come to mind:
>
> 1) The test isn't actually running under JDBC4?
>
> 2) The code coverage tool is providing an inaccurate report?
>
> 3) The decision about when to use LogicalPreparedStatement40 is
>    more complicated, and there is some other factor involved?
>
> Perhaps it would help if you posted a patch to JIRA, with instructions
> about the test you're trying, and others could try to reproduce the
> behavior you're seeing.
>
> thanks,
>
> bryan
>



-- 

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

Re: LogicalPreparedStatement40 code coverage

[Bryan Pendleton <bp...@gmail.com>]

> 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?

Three possibilities come to mind:

1) The test isn't actually running under JDBC4?

2) The code coverage tool is providing an inaccurate report?

3) The decision about when to use LogicalPreparedStatement40 is
    more complicated, and there is some other factor involved?

Perhaps it would help if you posted a patch to JIRA, with instructions
about the test you're trying, and others could try to reproduce the
behavior you're seeing.

thanks,

bryan

Re: Code coverage for client.net package

[Mohamed Nufail <nu...@gmail.com>]

Hi,


On Fri, Jul 6, 2012 at 12:45 PM, Knut Anders Hatlen
<kn...@oracle.com>wrote:

>
> 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
Undergraduate,
Department of Computer Science & Engineering,
University of Moratuwa.
Blog: http://www.nufailm.blogspot.com/

Re: Code coverage for client.net package

[Knut Anders Hatlen <kn...@oracle.com>]

Mohamed Nufail <nu...@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