db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6291) Improve code coverage of org.apache.derby.iapi.jdbc.BrokeredCallableStatement
Date Fri, 12 Jul 2013 08:53:49 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706797#comment-13706797
] 

Knut Anders Hatlen commented on DERBY-6291:
-------------------------------------------

One way to get the unsupported methods to show up in the coverage reports, provided they actually
are covered by the tests, is to make them explicitly throw an exception. See the corresponding
method in EmbedCallableStatement, which is reported as covered even though it always throws
an exception: https://builds.apache.org/job/Derby-JaCoCo/lastSuccessfulBuild/artifact/coverage-report/org.apache.derby.impl.jdbc/EmbedCallableStatement.java.html#L981

The downside of that approach is that the named parameter variants in BrokeredCallableStatement
won't automatically start working once support has been added to EmbedCallableStatement. I
think that is just a minor inconvenience that won't add any significant amount of extra work
when/if support for named parameter is added.

I think it makes sense to add test cases like the one Bryan suggested. It looks to me as if
we don't have such tests currently. The coverage we have of the named parameter methods probably
comes from tests like UnsupportedVetter and ClosedObjectTest that call all JDBC methods reflectively,
but they test a different aspect of the methods. I'd like the new test cases to be a bit more
specific, though. Something like:

CallableStatement cs = prepareCall("call TWO_IN_ONE_OUT_PROC (?, ?, ?)");
try {
    cs.setInt("P1", 6);
    fail("should have failed");
} catch (SQLFeatureNotSupportedException e) {
    assertSQLState("0A000", e);
}

Since we expect the setInt() call to fail, we shouldn't have calls to registerOutParameter()
and execute() in the try block. Otherwise, we cannot tell if it was the setInt() call that
failed expectedly, or some other call.
                
> Improve code coverage of  org.apache.derby.iapi.jdbc.BrokeredCallableStatement
> ------------------------------------------------------------------------------
>
>                 Key: DERBY-6291
>                 URL: https://issues.apache.org/jira/browse/DERBY-6291
>             Project: Derby
>          Issue Type: Sub-task
>          Components: JDBC
>            Reporter: ahsan shamsudeen
>            Assignee: ahsan shamsudeen
>            Priority: Minor
>
> According to code coverage analysis, org.apache.derby.iapi.jdbc.BrokeredCallableStatement
is 
> exercised poorly by of our regression tests. The current coverage report for this class
can be found at http://dbtg.foundry.sun.com/derby/test/coverage/_files/a9.html
> This task is to investigate this class, and either remove the unused code, or add
> regression test that exercise the code, as appropriate.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message