BiDirectionalEdgesDepthFirstSearchTest.testDisconnectedCycles:193->AbstractSearchTestCase.doIt:72 mismatched element at position 0 expected:<D> but was:<A>
DepthFirstSearchTest.testDisconnectedCycles:147->AbstractSearchTestCase.doIt:72 mismatched element at position 0 expected:<F> but was:<C>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I came across this error as well, so I did a bit of investigation and my view is that the test isn't valid because it depends on the values iterator from a HashMap being ordered. Ordering from HashMap.values() was pretty consistent up to Java 7, but it was never part of the specification. The changes in Java 8 have caught a lot of people out.
The expected CyclicTablesDependencyException is coming from here:
org.dbunit.database.CyclicTablesDependencyException: Table: A ([C, D, E])
at org.dbunit.database.DatabaseSequenceFilter$DependencyInfo.checkCycles(DatabaseSequenceFilter.java:302)
at org.dbunit.database.DatabaseSequenceFilter.sortTableNames(DatabaseSequenceFilter.java:112)
at org.dbunit.database.DatabaseSequenceFilter.<init>(DatabaseSequenceFilter.java:67)
at org.dbunit.database.DatabaseSequenceFilter.<init>(DatabaseSequenceFilter.java:76)
at org.dbunit.database.DatabaseSequenceFilterTest.testGetTableNamesCyclic(DatabaseSequenceFilterTest.java:103)
DatabaseSequenceFilter$DependencyInfo.checkCycles goes through each of the tables in the set, checking them for cyclical dependencies, but there are four tables in the test data with cyclical dependencies and in principle any one of them might come out first.
The test, imo, is only valid up to the point that an exception of the specific type can be expected: the assumption that table D will be the trigger is not reliable. Also, the tables in the expectedCycle set can't be presumed to be in any particular order, so comparing the toString isn't good either.
Incidentally, I was thrown off by the twisted bracketing in the assertion error message, with square and round brackets crossing each other. That seems to be a JUnit bug though. Stepping into the assert(...) call shows the compared strings to be "Table: D ([A, C, E])" and "Table: A ([C, D, E])", bracketed correctly.
[EDIT]
The above is specific to testGetTableNamesCyclic, but there is a more visible problem behind the testDisconnectedCycles failures. AbstractSearchTestCase.doIt() expects two sets to have the same elements in the same order, which isn't fair game. It should be using the equals() method.
Last edit: Joe Kearns 2017-06-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me know if there's anything else I can pitch in with.
:-) Joe, do you have time to update the tests to work with Java 8? Your analysis above agrees my my initial look. Regarding assertion on ordering, Matchers.containsInAnyOrder() may prove useful in some of these updates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've added fixes to my fork: DatabaseSequenceFilterTest - only check that the appropriate exception is raised AbstractSearchTestCase - use equals() to verify that the two sets contain the same members (in any order)
Jeff, if you're happy enough with the changes I'll create a merge request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DatabaseSequenceFilterTest.testGetTableNamesCyclic:112 expected:<Table: <span="">[D ([A, C], E])> but was:<Table: <span="">[A ([C, D], E])>
BiDirectionalEdgesDepthFirstSearchTest.testDisconnectedCycles:193->AbstractSearchTestCase.doIt:72 mismatched element at position 0 expected:<D> but was:<A>
DepthFirstSearchTest.testDisconnectedCycles:147->AbstractSearchTestCase.doIt:72 mismatched element at position 0 expected:<F> but was:<C>
I came across this error as well, so I did a bit of investigation and my view is that the test isn't valid because it depends on the values iterator from a HashMap being ordered. Ordering from HashMap.values() was pretty consistent up to Java 7, but it was never part of the specification. The changes in Java 8 have caught a lot of people out.
The expected CyclicTablesDependencyException is coming from here:
org.dbunit.database.CyclicTablesDependencyException: Table: A ([C, D, E])
at org.dbunit.database.DatabaseSequenceFilter$DependencyInfo.checkCycles(DatabaseSequenceFilter.java:302)
at org.dbunit.database.DatabaseSequenceFilter.sortTableNames(DatabaseSequenceFilter.java:112)
at org.dbunit.database.DatabaseSequenceFilter.<init>(DatabaseSequenceFilter.java:67)
at org.dbunit.database.DatabaseSequenceFilter.<init>(DatabaseSequenceFilter.java:76)
at org.dbunit.database.DatabaseSequenceFilterTest.testGetTableNamesCyclic(DatabaseSequenceFilterTest.java:103)
DatabaseSequenceFilter$DependencyInfo.checkCycles goes through each of the tables in the set, checking them for cyclical dependencies, but there are four tables in the test data with cyclical dependencies and in principle any one of them might come out first.
The test, imo, is only valid up to the point that an exception of the specific type can be expected: the assumption that table D will be the trigger is not reliable. Also, the tables in the expectedCycle set can't be presumed to be in any particular order, so comparing the toString isn't good either.
Incidentally, I was thrown off by the twisted bracketing in the assertion error message, with square and round brackets crossing each other. That seems to be a JUnit bug though. Stepping into the assert(...) call shows the compared strings to be "Table: D ([A, C, E])" and "Table: A ([C, D, E])", bracketed correctly.
[EDIT]
The above is specific to testGetTableNamesCyclic, but there is a more visible problem behind the testDisconnectedCycles failures. AbstractSearchTestCase.doIt() expects two sets to have the same elements in the same order, which isn't fair game. It should be using the equals() method.
Last edit: Joe Kearns 2017-06-27
:-) Joe, do you have time to update the tests to work with Java 8? Your analysis above agrees my my initial look. Regarding assertion on ordering, Matchers.containsInAnyOrder() may prove useful in some of these updates.
I've added fixes to my fork:
DatabaseSequenceFilterTest - only check that the appropriate exception is raised
AbstractSearchTestCase - use equals() to verify that the two sets contain the same members (in any order)
Jeff, if you're happy enough with the changes I'll create a merge request.
Nice simple changes, thank you Joe!
Yes, please create the merge request.
Updated thanks to Joe Kearns in merge request https://sourceforge.net/p/dbunit/code.git/merge-requests/36/