db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6284) Improve test coverage of org.apache.derby.iapi.db.ConnectionInfo
Date Thu, 04 Jul 2013 15:49:49 GMT

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

Bryan Pendleton commented on DERBY-6284:

I've been studying this issue and thinking about the proposal 
to remove ConnectionInfo.lastAutoincrementValue.

If we do this, I think we should update the JavaDoc comments in
LanguageConnectionContext.java and in GenericLanguageConnectionContext.java

         * @see org.apache.derby.iapi.db.ConnectionInfo#lastAutoincrementValue
     * Implements ConnectionInfo.lastAutoincrementValue.
     * @see org.apache.derby.iapi.db.ConnectionInfo#lastAutoincrementValue
     * @see org.apache.derby.iapi.db.ConnectionInfo#lastAutoincrementValue

As I was studying this, I was confused by the comment in
GenericLanguageConnectionContext.lastAutoincrementValue that says:

     * Implements ConnectionInfo.lastAutoincrementValue.

At first I thought this meant "implements" as in normal Java interface-implementation 
usage; in that use of the word, GenericLanguageConnectionContext.lastAutoincrementValue
"implements" LanguageConnectionContext.lastAutoincrementValue and
GenericLanguageConnectionContext.autoincrementFlushCache "implements"

But, what this comment actually means is: "ConnectionInfo.lastAutoincrementValue
is a wrapper routine, which calls GenericLanguageConnectionContext.lastAutoincrementValue
to do all the work."

Which is a different sense of the word "implements". Still valid, but different.

As I was looking at the code in GenericLanguageConnectionContext, I noticed
that, according to the Emma report in http://dbtg.foundry.sun.com/derby/test/coverage/_files/b5.html,
neither lastAutoincrementValue() nor autoincrementFlushCache() is called at all by
our regression suite.

However, when I look at http://dbtg.foundry.sun.com/derby/test/coverage/_files/3cf.html,
I see that the Emma report for InsertResultSet says that lines 1118-1124 ARE executed:

            Long initialValue =
                      (s = constants.getSchemaName()),
                      (t = constants.getTableName()),
                      (c = constants.getColumnName(i)));

and the report also says that line 1384 IS executed:


So now I'm confused: if these lines are executed, how is it that the corresponding
implementation code in GenericLanguageConnectionContext is NOT executed?

Is this a flaw in the Emma analysis?

To summarize:

- if we decide to remove ConnectionInfo.lastAutoincrementValue, we
  should update the JavaDoc comments in LanguageConnectionContext.java
  and GenericLanguageConnectionContext.java

- something is strange about the Emma coverage report for
   GenericLanguageConnectionContext, because it claims that the
  lastAutoincrementValue and autoincrementFlushCache methods are not
  executed, even though the Emma report for InsertResultSet shows that
  those methods ARE executed.

Before proceeding with this patch, I'd like to better understand both the above.

> Improve test coverage of org.apache.derby.iapi.db.ConnectionInfo
> ----------------------------------------------------------------
>                 Key: DERBY-6284
>                 URL: https://issues.apache.org/jira/browse/DERBY-6284
>             Project: Derby
>          Issue Type: Sub-task
>          Components: JDBC
>            Reporter: Bryan Pendleton
>            Assignee: ahsan shamsudeen
>            Priority: Minor
>         Attachments: DERBY-6284.patch
> According to code coverage analysis, org.apache.derby.iapi.db.ConnectionInfo is 
> not currently being exercised by any of our regression tests.
> 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

View raw message