#164 Remove JUnit dependency

[Felipe Leme]

DbUnit can be integrated to TestNG, by using IDatabaseTester implementations instead of extending DbTestCase. But the AbstractDatabaseTester uses Junit asserts, which makes it mandatory to include the junit.jar in your project, or provide a hack such as creating the class below :

package junit.framework;

import org.testng.AssertJUnit;

public class Assert extends AssertJUnit {

}

[matthias g]

I'd go even a step further and would say the dbunit could provide more information on an assertion failure. For example all data of all tables could be compared and all differences could be reported instead of a failure when the first difference was detected. Therefore we could introduce "Assertion.compare()" methods in addition to the "Assertion.assertEquals()" methods which simply return some kind of a difference object.

Basically it would be great to have an own dbunit framework for reportion assertion failures. The classes I found that currently depend on junit are:
- org.dbunit.util.FileAsserts
- org.dbunit.Assertion
- org.dbunit.DatabaseTestCase

I removed the dependencies from
- org.dbunit.Assertion
- org.dbunit.util.FileAsserts

by improving the FailureHandler interface and adding an implementation for JUnit. This JUnit implementation is used by default now in the org.dbunit.Assertion methods, but can be passed in as an additional argument (if you like to use TestNG, for example).

Perhaps we could also remove the dependency to JUnit from the DatabaseTestCase class using the FailureHandler interface.

Please feel free to improve this (for example reading the FailureHandler dynamically from a SystemProperty) or to add some comments on this.

My commit is svn rev 864/trunk.

Regards,
mat

[Felipe Leme]

Hi Mathias,

First of all, thanks for the effort making the project cleaner.

Now, some comments:

> Perhaps we could also remove the dependency to JUnit from the
> DatabaseTestCase class using the FailureHandler interface.

I think that's not necessary, as DatabaseTestCase is meant for JUnit - it relies on setup() and teardown(), for instance. What we could do in the future is to split the project in sub-projects with its own jars (dbunit-core, dbunit-junit, dbunit-testng, dbunit-all.jar, etc...), so these framework-specific classes would belong to the proper sub-project.

> Therefore we could introduce "Assertion.compare()" methods in addition to the
> "Assertion.assertEquals()"

Adding such a method could cause confusion, because calling these methods assertXXX is kind of an idiom on test frameworks. OTOH, the current assertEquals() method is not flexible enough, so we could do some refactoring in this method (I will talk more about it in the dev's list).

[]s,

-- Felipe

[matthias g]

Hi Felipe,

here my comments on this:

> I think that's not necessary, as DatabaseTestCase is meant for JUnit - it
> relies on setup() and teardown(), for instance. What we could do in the
> future is to split the project in sub-projects with its own jars
> (dbunit-core, dbunit-junit, dbunit-testng, dbunit-all.jar, etc...)

You are right. Since there are only 2 classes that depend on JUnit directly at the moment I am not sure if it is worth the effort creating an extra jar for them. (These classes are JUnitFailureHandler and DatabaseTestCase)

>> Therefore we could introduce "Assertion.compare()" methods in addition
>> to the "Assertion.assertEquals()"

> Adding such a method could cause confusion, because calling these methods
> assertXXX is kind of an idiom on test frameworks.

Do you know xmlunit? It is a very good example for the case we are facing in dbunit as well. A dbunit assertion is not kind of a "single unit of work" assertion as is a normal JUnit test. Instead it compares a whole bunch of data. For evaluating the cause of a test failure it might be helpful if one could retrieve all rows/columns that did not match instead of only the first one. (This is the same way xmlunit compares two xml strings - you can retrieve the diff for the whole document). I will think about a potential solution and will keep you in the loop. I will open a new request for this.

Regards,
mat

[matthias g]

Hi Felipe,

I have another suggestion for clarifying the dependencies dbunit currently has on JUnit. What about creating a package "org.dbunit.junit" which contains all JUnit specific stuff? I think these are currently the following:

- JUnitFailureFactory
- DatabaseTestCase (+ inherited DBTestCase + inherited classes DataSourceBasedDBTestCase/JdbcBasedDBTestCase/JndiBasedDBTestCase)
- ant.DbUnitTask

The only problem I currently see is the DbUnitAssert which uses the JUnitFailureFactory for backwards compatibility reasons.

Regards,
mat

[Viczian Istvan]

I think there are two solutions:

• More modules: for some classes it is to much effort.
• Mark JUnit dependency as optional. And it is a good practice to move the things depend on JUnit to a separate package.

[Jeff Jensen]

Also see https://sourceforge.net/p/dbunit/feature-requests/222/