Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support DatabaseSequenceFilter #46

Open
davidkarlsen opened this issue Jun 23, 2016 · 6 comments
Open

support DatabaseSequenceFilter #46

davidkarlsen opened this issue Jun 23, 2016 · 6 comments

Comments

@davidkarlsen
Copy link
Contributor

It would be nice to be able to use DatabaseSequenceFilter in order to order the table actions automatically by FK refs to avoid constraint violations w/o having to order the tables manually in the datasets.

http://dbunit.sourceforge.net/faq.html#fkconstraintviolation
http://dbunit.sourceforge.net/apidocs/org/dbunit/dataset/FilteredDataSet.html

@davidkarlsen
Copy link
Contributor Author

@slandelle Any thoughts or implementation hints on this?

@slandelle
Copy link
Contributor

@davidkarlsen Honestly, no idea. I'll be honest: I no longer use this project and really don't have time to do anything more than accepting contributions and dealing with releases.

@davidkarlsen
Copy link
Contributor Author

davidkarlsen commented Jun 29, 2016

@slandelle OK - nice to know - have you found better alternatives for the same functionality (e.g. integrating dbunit nicely into spring based integration tests)?

Seems like this might be the way to go: https://github.com/springtestdbunit/spring-test-dbunit

@slandelle
Copy link
Contributor

Several things:

  • I mostly develop in Scala now and don't have a use for Spring
  • I ended up realizing moking your real database with an in-memory one was a bad idea as you're not testing the real thing and would have to stick to features that are available in both, which is a real pity. I'd rather restore some database image and run this kind of tests in CI instead of embedded.

@davidkarlsen
Copy link
Contributor Author

Definitively use the proper database - that's what we do. But being able to run small datasets per test and [mostly] be able to roll it away after the test is very nice (to the extent that integration-tests are the way to go - we favour unit-tests)

@slandelle
Copy link
Contributor

And one last thing: I really ended up hating dbunit:

  • weirdness, ex: schema inferred from first record of a given table, so if you have optional columns, you must have them all present in the first record, otherwise they're just silently ignored
  • files format

If I really was to conduct db tests this way, I'd rather use DbSetup instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants