Menu
▾
▴
#219 problem when verifying against an XmlDataSet
I just copy/paste the whole communication here:
Hi Matthias,
I'm surprised the test works on your machine. To isolate the issue, I've
created a standalone maven project that contains just this single test
case. However, I am not using the dbunit-maven-plugin to run dbunit from
the maven lifecycles. Instead, I simply configured the dbunit jar as a
regular dependency (this is similar to how dbunit is used in our
ant-based build process).
To run the project I first manually installed dbunit 2.4.2 as a maven
dependency:
$ mvn install:install-file -DgroupId=dbunit -DartifactId=dbunit
-Dversion=2.4.2 -Dpackaging=jar -Dfile=dbunit-2.4.2.jar
Running the test then gives me the same problem as before:
$ mvn test
[INFO] Scanning for projects...
<snip>
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.371
sec <<< FAILURE!
Results :
Failed tests:
testDataSet(com.test.DBUnitTest)
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
I've attached both the isolated maven project, as well as the surefire
test report. Given the fact this is now a completely standalone project,
I would expect it to either succeed or fail, regardless of the OS,
machine, or environment (ps. I'm on OSX).
cheers,
Erik
Matthias Gommeringer wrote:
> Hi Erik,
>
> I re-ran your test again on my linux box and it is still green - without any modifications (yesterday on my windows box it was green as well). I currently do not have any idea what this could be...sorry. It would be nice if I could reproduce it somehow.
>
> Best regards,
> matthias
>
>> -----Ursprüngliche Nachricht-----
>> Von: "Erik van Zijst" <erik.van.zijst@gmail.com>
>> Gesendet: 23.12.08 00:00:33
>> An: dbunit-user@lists.sourceforge.net
>> Betreff: Re: [dbunit-user] ComparisonFailure: expected table count in error?
>
>
>> Hi Matthias,
>>
>> I realize the tables must be present in the database before loading data
>> into it through DBUnit. However, my test does not read the data from the
>> database, but from the hardcoded xml file declared as a private member
>> in the test class (or at least that's what I want and expect it to do;
>> please correct me if I'm wrong).
>>
>> But you say that my testcase passes when you run it unchanged?
>>
>> cheers,
>> Erik
>>
>>
>> Matthias Gommeringer wrote:
>>> Hi Erik,
>>>
>>> I ran your testcase and it is green on my machine.
>>> The "NoSuchTableException" actually means that the table does not exist in your HSQLDB. If I change the methods as follows I get the same exception:
>>>
>>> protected IDataSet getDataSet() throws Exception {
>>> return new XmlDataSet(new StringReader(xml));
>>> }
>>>
>>> public void testDataSet() throws Exception {
>>> assertEquals(3, new XmlDataSet(new StringReader(xml)).getTableNames().length);
>>> assertNotNull(new XmlDataSet(new StringReader(xml)).getTable("TEST_TABLE"));
>>>
>>> IDataSet databaseDataSet = getConnection().createDataSet(); // Here the exception is thrown
>>> assertEquals(3, databaseDataSet.getTableNames().length);
>>> }
>>>
>>> In order to make this work you have to execute the DDL to create the table in advance to doing the CLEAN_INSERT from DbUnit.
>>>
>>> Hope this helps,
>>> matthias
>>>
>>>
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: "Erik van Zijst" <erik.van.zijst@gmail.com>
>>>> Gesendet: 22.12.08 04:31:15
>>>> An: dbunit-user@lists.sourceforge.net
>>>> Betreff: [dbunit-user] ComparisonFailure: expected table count in error?
>>>
>>>> Hi folks,
>>>>
>>>> I'm running into a problem with dbunit 2.4.1 and 2.4.2 when verifying
>>>> the contents of my hsqldb database against an XmlDataSet (as done in the
>>>> "Sample" paragraph of http://dbunit.sourceforge.net/howto.html\).
>>>> Assertion.assertEquals(IdataSet, IDataSet) keeps failing with:
>>>>
>>>> junit.framework.ComparisonFailure: table count
>>>> Expected :0
>>>> Actual :3
>>>> at
>>>> org.dbunit.assertion.JUnitFailureFactory.createFailure(JUnitFailureFactory.java:39)
>>>> at
>>>> org.dbunit.assertion.DefaultFailureHandler.createFailure(DefaultFailureHandler.java:105)
>>>> at org.dbunit.assertion.DbUnitAssert.assertEquals(DbUnitAssert.java:228)
>>>> at org.dbunit.assertion.DbUnitAssert.assertEquals(DbUnitAssert.java:196)
>>>> at org.dbunit.Assertion.assertEquals(Assertion.java:104)
>>>> at
>>>> com.atlassian.crucible.migration.HSQLDBImporterTest.testImport(HSQLDBImporterTest.java:143)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
>>>>
>>>> It does see the 3 tables in my hsql database, but doesn't see the
>>>> content in the xml file.
>>>>
>>>> I've attached a small unittest that illustrates the problem. It fails on
>>>> lines 58 and 59 when trying to read the data in the XmlDataSet:
>>>>
>>>> 58: junit.framework.AssertionFailedError: expected:<3> but was:<0>
>>>> 59: org.dbunit.dataset.NoSuchTableException: TEST_TABLE
>>>>
>>>> Is this supposed to fail? If so, how should I go about verifying the
>>>> contents of my database?
>>>>
>>>> kind regards,
>>>> Erik
dbunittest-with-maven-reproducible
Hi Erik,
I am now able to reproduce the problem. So thanks a lot for your new testcase.
I debugged through this and found that something weird is happening in the maven-call which
is not happening when executing the test within eclipse's junit runner. The "AbstractDataSet#getTableNames()" is
invoked before the XML actually has been parsed into the CachedDataSet. So the "AbstractDataSet#_orderedTableNameMap"
is initialized emptily and all later invocations will use this lazily initialized "_orderedTableNameMap" (this is the reason why it is always empty in your case).
After some more debugging I found out that the "AbstractDataSet#toString()" method invokes the "AbstractDataSet#getTableNames()" which
was responsible for the premature initialization of the "_orderedTableNameMap". This happened only when invoked via maven invoked because (in my case at least) a logger was configured with the level DEBUG.
I created item #2475264 in the tracker for handling this bug (I took the freedom to copy/paste our mail correspondence there).
I already committed the bugfix in to SVN revision 930/trunk. Please feel free to build it on your own or to retrieve the latest snapshot build from parabuild ( http://parabuild.viewtier.com:8080/parabuild/build/results.htm?buildrunid=11264 ).
Best regards,
Matthias