db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: [jira] Commented: (DERBY-2299) convert cursor.java to junit
Date Tue, 13 Feb 2007 18:12:09 GMT
On 2/12/07, Daniel John Debrunner (JIRA) <jira@apache.org> wrote:
>
>    [ https://issues.apache.org/jira/browse/DERBY-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472525
]
>
> The use of assertEquals in the converted test has the arguments the wrong way around.
>
>                assertEquals(1956, cursor.getInt(1));
>                assertEquals("hello world", cursor.getString(2).trim());
>
> http://www.junit.org/junit/javadoc/3.8.1/junit/framework/Assert.html
>
> static void     assertEquals(int expected, int actual)
>

This comment confused me. It seems to me that in the above examples
the expected int *is* the first parameter, and the actual *is* the
second, so those are correct....Or am I missing something there?

I did see one instance of assertEquals in the test where the expected
and actual appeared reversed:
    assertEquals(cursor.getCursorName(),"ForCoverageSake");


Then, To reply to Kathey's question:
>>I wonder whether we should test the different states in the test or
change the >>client SQLState to match embedded.

The documentation clearly states that differences in SQLState are
expected. (http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclientdiffs.html).
Changing the SQLState to match embedded may be what we ought to do in
the bigger scheme of things, but I think it goes completely out of the
scope for this JIRA. You could log a separate bug for it. There may
already be a bug existing (I have not searched).

Finally, I have two nits:
- the file was committed(revision 506709) but no cross-reference was
done to the JIRA. I think it would be nice if that's done. I know not
everyone does this all the time, though.
- the new file has a mix of spaces and tabs. While I find that
acceptable in old code I think we should attempt a clean setup in new
code.

But - like I said, those are just nits.

Myrna

Mime
View raw message