test/table.java uses reverse order in assertEquals()

[ghost]

Reported by @cristianbogdan on 27 Oct 2002 00:09 UTC "ant test" seems to have a problem with testing the value of entered dates

 [java] 1) testInsert(test.table)junit.framework.AssertionFailedError:

expected:<1977-03-05 00:00:00.0> but was:<Sat Mar 05 00:00:00 CET 1977>

at least with java 1.4.1

Migrated-From: http://trac.makumba.org/ticket/75

[ghost]

Comment by @cristianbogdan on 27 Oct 2002 00:25 UTC just confirmed this on unix with both java 1.3 and 1.4

[ghost]

Comment by @stefanb on 30 Oct 2002 02:54 UTC Test compared objects: class java.sql.Timestamp: 1977-03-05 00:00:00.0 and class java.util.Date: Sat Mar 05 00:00:00 CET 1977

after checking http://java.sun.com/j2se/1.3/docs/api/java/sql/Timestamp.html#equals (java.lang.Object) and noticing that Timestamp.equals(Object) is not symetric with respect to the equals(Object) method in the base class (Date), meaning that Timestamp.equals(Object) understands Date as parameter, but Date.equals(Object) does not (it fails if parameter is not of type Date).

and after checking: http://junit.sourceforge.net/javadoc/junit/framework/Assert.html and noticed that the order matters - assertEquals(actual, expected) which is reversed in most places.

...it became clear why it fails - because it is not returning the same object type

I reversed assertEquals() parameters and no error was reported anymore.

After adding a new test: assertEquals("Birthdate class", birth.getClass(), pc.get ("birthdate").getClass() ); a new readable problem is shown: [1) testInsert(test.table)junit.framework.AssertionFailedError: Birthdate class expected: but was:<class java.sql.Timestamp> java at test.table.testInsert(table.java:99) [java] at test.table.main(table.java:20)

Should it return Date instead of Timestamp, or is this new test a nonsense?

[ghost]

Comment by @cristianbogdan on 30 Oct 2002 10:36 UTC good work!

and noticed that the order matters - assertEquals(actual, expected) which is reversed in most places. ok, so the whole table.java should be corrected in respect to this... and committed to CVS.

assertEquals("Birthdate class", birth.getClass(), pc.get ("birthdate").getClass() );

no need for this test. it's normal for 2 objects to be of different classes (coming from the same ancestors), and yet one to be equal() to the other (and, as we learn here, the other not to be equal() to the first)

[ghost]

Comment by @stefanb on 30 Oct 2002 11:35 UTC reversed assertEquals() parameters where needed (some cases were ok as they were) and committed test.java,v1.18, which currently passes with flying colors

...so probably more evil tests should be put in there :)