search

springtestdbunit / spring-test-dbunit

Integration between the Spring testing framework and DBUnit
http://springtestdbunit.github.com/spring-test-dbunit/
Apache License 2.0
475 stars 238 forks source link

add support for datasets to be programmatically generated as well as loaded from static files #116

Open mutsys opened 8 years ago

mutsys commented 8 years ago

I have projects which contain some rather large and complex pojo - db mappings. As I refactor the db schemas and domain over the life of a project, maintaining the data sets for setup/assertion as xml files quickly becomes a laborious and tedious task. Having the ability to programmatically create datasets would be a great addition. We should be able to do some like:

@DatabaseSetup(dataset=MyGeneratedDataset.class)

I have actually hacked together some support for this in one of my current projects and it has turned out to be a lifesaver. What would have otherwise been the unpleasant effort of updating 50+ xml files is now a small, quick refactoring of my dataset generators. It also makes possible tests for query operations that might otherwise go untested due to the large number of rows needed in potentially many tables. Am I correct in thinking that others would benefit from this as well?

FingolfinTEK commented 8 years ago

Hmmm, I agree that this is would be a cool feature but you can already supply your own DataSetLoader - through @DbUnitConfiguration. From within your loader you can provide whatever DataSet you desire. True, DbUnitConfiguration - and thus the loader - can only be applied to the whole test class, but that doesn't seem like that big of a limitation.

mutsys commented 8 years ago

Yes, in fact that is what I have done. In addition to a custom DataSetLoader (GeneratedDataSetLoader), I also created a complimentary DataSetGenerator that works along with it as well as GeneratedDataBuilder, RowBuilder and TableBuilder that provide the DataSetGenerator with a source of ITables. Having to apply the DbUnitConfiguration with GeneratedDataSetLoader to the entire test class has not been a limitation at all. Overall, I am pretty happy with the gains I've gotten for not that much effort so far.

The only thing that gives me a bit of hesitation before taking the plunge and sending a pull request is that currently it seems that there is much in the current implementation that is kind of hard wired to the current attributes of @DatabaseSetup/@ExpectedDatabase/@DatabaseTeardown and FlatXmlDataSetLoader. The refactoring required to more loosely couple DbUnitTestExecutionListener and loaders might turn out to be a considerable amount of work. Not that the effort itself is much of a deterrent, I'm more concerned that if the amount of code I would need to refactor is significant, any design choices I make might be considered undesirable by other contributors and potentially interfere their contributions. Is this a valid concern or is this just unwarranted anxiety?

FingolfinTEK commented 8 years ago

I think it is a valid concern; and while there are occasional contributors, the only one doing regular development is @philwebb so I think it would probably be best if you wait for his two cents.

For my part, I think the changes have merit and would very much like to see an example of your GeneratedDataSetLoader so maybe you could add a simplified example to the sample project, as a start?

mutsys commented 8 years ago

Thanks for the feedback Milos, very interested in hearing what @philwebb has to say as well.

I would be happy to contribute an example. It might not happen too quickly due to my other commitments but I will definitely put together an example for you as soon as I am able.