[bmajsak]

Updated JIRA for cleanup operation

https://issues.jboss.org/browse/ARQ-755

https://issues.jboss.org/browse/ARQ-777

[bmajsak]

I opened seperated thread to discuss cleanup / seeding and custom scripts https://community.jboss.org/thread/195815

Looking forward to your feedback!

[shogz]

Hi,

sorry for replying late, there is quiet some work around lately ^^. Thx for the nice feedback Dan and Bartosz.

For the column filter feature. I like your idea, Dan. It quiet meets the goal of this extension to simplify DB testing. But there's a bunch of use cases where static handler class will not provide the flexibility needed. E.g a timestamp doesn't need to be a temporal type. One might have good reasons to use Varchar. There might be as well temporal fields which can actually be predicted. Concider testing a planning tool. So I'd preferably go with Bartosz's solution to provide both with the option of creating new handlers or inherit from existing ones. This would be a great improvement in flexibility. For A4 release I'd be pretty happy with simply passing the IColumns feature ;-).

One other thought I had. I recently had some mail discussion with Bartosz regarding the cleanup method. DBUnit suffers from its inability to properly handle foreign key constraints for years now. My solution was to fork your code and do some handish truncate on a generated Dataset to clean the DB (Bartosz has the code). DBUnit truncate doesn't work since it creates a batch process with one truncate per table. Doing this, truncate has exactly the same effect as delete_all ^^. This is obviously a behaviour you won't expect from DBUnit and since there hasn't been much development recently you might concider to bundle DBUnit with your own code, so you can handle such issues better.

However I'm looking forward to A4 ^^. Keep it up!

Cheers

Michael

[jjfraney]

I'd like to see the data fixture definition and java test class in the same file.  Also, I'd like to easily navigate from the test class to the fixture definition.

Aside from the lowlevel (non entity) nature of dbunits fixture expression, the part of dbunit that ties me into knots (and I'm not picking on dbunit) is that data fixture is described in a way that does not allow for easy navigation between the test class and the fixture definition file.  AFAIK, the eclipse IDE does not have a natural mechanism to link the non-java file resource and the java test class.  So, there is agrravating delay as I switch from looking at the test to looking at the data fixture: First, read the test class to find the name of the fixture's filename and folder, click on eclipse project view to find the folder and the file, open the file, split the editors to see fixture and test class side by side.

Because I don't like flipping between files, nor reading the dbunit xml dataset files, I've started a practice of setting the fixture with JPA in a before method of the test class.  This keeps the fixture and the test in the same file.  And, in my test classes I give the fixture setup method a name from convention to easily find it in the IDE's outline view.  These steps have helped.  I wish I could bind the navigation to a key stroke, like eclipse's F3 "Open Declaration" command.

[jmnarloch]

Hi Bartosz,

I was wondering if you had anyhow explored the idea regardring NoSQL support? Currently I don't thing that there is any solution for running integration test with CouchDB or MongoDB. So I guess that providing that support in even limited scope would be quite unique in comparison to other dbunit testing solutions.

[bmajsak]

Hi Jakub,

as you can see it's on the roadmap, so certainly it is really worth to dive into the topic. I'm working on the modularization of APE now, so it will open nice integration points where we can abstract away DBUnit stuff from the current "core" and provide other things such as NoSQL and Liquibase support. If you have some concrete ideas I'm keen to hear them

Cheers,

Bartosz

[jmnarloch]

Currently my idea was quite general but I can already find a use case for that - using APE for testing Spring Data MongoDB. We would not need any tide integration with that particular framework only abstraction of the underlying data store. Anyway I find that quite interesting area to explore.

[aslak]

One question that came up at the last JUG was:

This can run in SE as well right ?

Technically it should be possible to provide a APE SE version as it's only depended on the Container bits for Packaging as far as I know.

A Local transaction manager + a EntityManager factory should work?