Hir Luigi, About @ExpectedDatabase, its fine I just don't like it hehe a matter of taste probably ;)
About @DatabaseTest I still not convinced that you need it, just an entityManager instance wouldn't be sufficient to create a transaction and load the dataset? I have implemented an interceptor (simpler than yours) that loads datasets using a produced entity manager see [1] and [2]. About junit rule for dbunit I also have implemented something, see [3]. If you find something useful there just grab it ;) [1] https://github.com/rmpestano/dbunit-rules/blob/master/cdi/src/main/java/com/github/dbunit/rules/cdi/DBUnitInterceptor.java [2] https://github.com/rmpestano/dbunit-rules/blob/master/cdi/src/main/java/com/github/dbunit/rules/cdi/DataSetProcessor.java [3] https://github.com/rmpestano/dbunit-rules/blob/master/core/src/main/java/com/github/dbunit/rules/DBUnitRule.java 2016-02-18 16:33 GMT-02:00 Luigi Bitonti <[email protected]>: > Hi Rafael, > > To load data in the db (@DatabaseSetup) and run verification/teardown > operations there's a need for a jdbc connection to pass to dbunit. There > are currently 2 ways to do that: > > 1) @DatabaseTest (and @DatabaseNoRollbackTest) obtains an entity manager > from the current transaction and unwraps a connection from that. > > 2) DbUnitTestRule is a JUnit rule that allows you to avoid all of the > above as it simply wraps a test and executes setup, expected db check and > teardown. No transactions started there or rolled back or committed at the > end. It also saves you some annotations. It is less tested than the > interceptors above, but it seems to work. You can find example usages in > the deltaspike-dbunit-sample application (InventoryServiceRuleTest.java). > > The idea behind 2) was to split the application in a core module (not > dependent on deltaspike) using a simple junit rule and a deltaspike module > in a separate jar that allows to work with "transactional tests" as in 1). > I haven't got around to do that (yet). > > I find @ExpectedDatabase very useful and more than once it showed me I had > introduced bugs I did not even imagine. It is quite hard to verify all > fields that could be involved in most operations of non-trivial > applications and an external representation of the db state makes that much > easier and effective in my opinion. > > It should definitely be possible to have a dataset loader which tries to > guess the dataset format and probably it should be the default one. I'll > try to have a look after I work on your pull request. > > Cheers, > Luigi > > > > On Wednesday, February 17, 2016 7:31 PM, Rafael Pestano < > [email protected]> wrote: > Hi Luigi, > > If I don't use @ExpectedDataSet or @rollback then I don't need transactions > at test level, right? > > I really don't get/like the matching dataset strategy, I think the > assertion must be part of the test and not in some external file that > represents the database state after the test. > > About Dataset loader do you think its possible to "guess" it looking at > Dataset name sulfix, e.g users.yml should activate yaml Dataset loader > > Em qua, 17 de fev de 2016 16:26, Luigi Bitonti <[email protected] > > > escreveu: > > > > Hi Jan, > > > > Thanks for your feedback. It looks like this is a much sought after > > feature. Anyone for a pull request? :-) I suspect the change would not be > > possible without some code duplication between @DatabaseTest and > > @DatabaseTestNoRollback, but I might be wrong. > > > > Cheers, > > Luigi > > > > > > > > On Wednesday, February 17, 2016 6:17 PM, Jan Matèrne (jhm) < > > [email protected]> wrote: > > Instead of having so many annotations, why not combine them? > > > > @RunWith(CdiTestRunner.class) > > @DbUnitConfiguration(dataSetLoader = YamlDataSetLoader.class) > > @DatabaseTest > > @DatabaseSetup(value="../setup-db.yml", > > type=DatabaseOperation.CLEAN_INSERT) > > > > to > > > > @RunWith(CdiTestRunner.class) > > @DatabaseTest( > > setup="../setup-db.yml" > > dataSetLoader=YamlDataSetLoader.class // optional, defaults according > > the suffix of #setup > > type=DatabaseOperation.CLEAN_INSERT // optional, useful default here > > ) > > > > > > Jan > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Rafael Pestano [mailto:[email protected]] > > > Gesendet: Mittwoch, 17. Februar 2016 03:45 > > > An: [email protected] > > > Betreff: Re: deltaspike dbunit > > > > > > Hi again, > > > > > > Just sent a PR <https://github.com/lbitonti/deltaspike-dbunit/pull/1> > > > for yaml and json datasets. > > > > > > One thing that Im not happy (probably because I always use yml) is that > > > have to add an extra annotation to say what kind of dataset we are > > > working on, so my test looks lke this: > > > > > > @RunWith(CdiTestRunner.class) > > > @DbUnitConfiguration(dataSetLoader = YamlDataSetLoader.class) > > > @DatabaseTest @DatabaseSetup(value = "../setup-db.yml", type = > > > DatabaseOperation.CLEAN_INSERT) > > > > > > > > > @DatabaseTest to enable transactions, I really don't use this on my > > > tests cause transactions in my app are handle by CDI (but I see I would > > > need this if transactions were managed by ejbs or spring for example). > > > Also if possible would try to reuse @Transactional from deltaspike > > > here. > > > > > > @DbunitConfiguration: here I think we could infer dataset loader from > > > dataset name sulfix or use a global configuration class/ file because > > > you usually will use one type of dataset in a project. > > > > > > @DatabaseSetup is to only annotation I want in 90% of my dbunit tests. > > > > > > > > > WDYT? > > > > > > About the tests, can you run them through the IDE? when I run in the > > > IDE derby is not started, with maven everything is ok. > > > > > > > > > 2016-02-16 18:57 GMT-02:00 Rafael Pestano <[email protected]>: > > > > > > > Hi Luigi, > > > > > > > > great job, I'm a big fan of dbunit. > > > > > > > > I have some questions: > > > > > > > > why do you need @DatabaseTest annotation, only @DatabaseSetup > > > wouldn't > > > > be sufficient? > > > > > > > > do you plan to support other dataset types like yml or json? > > > > > > > > There is a way to execute scripts before and after the test? > > > > > > > > I see that we can attach replacers however a common use case is to > > > use > > > > relative dates in datasets, there is plan for a built in datetime > > > replacer? > > > > > > > > I already have implemented some of the items above and can contribute > > > > if you have interest. > > > > > > > > thank you for porting it to deltaspike! > > > > > > > > > > > > 2016-02-16 15:18 GMT-02:00 Gerhard Petracek <[email protected]>: > > > > > > > >> hi luigi, > > > >> > > > >> it's great that you share it with the community! > > > >> we can link it in our documentation! > > > >> > > > >> regards, > > > >> gerhard > > > >> > > > >> > > > >> > > > >> 2016-02-16 11:40 GMT+01:00 Luigi Bitonti > > > <[email protected]>: > > > >> > > > >> > Hi All, > > > >> > > > > >> > I've released recently a library that allows integration between > > > >> > Deltaspike TestControl and DBUnit. It allows, using simple > > > >> > annotations, > > > >> to > > > >> > setup and teardown database tables as well as checking expected > > > >> > table contents once a test completes. > > > >> > > > > >> > Basically something like: > > > >> > > > > >> > > > > >> > @DatabaseTest@DatabaseSetup("../setup-db.xml") > > > >> > .... > > > >> > @ExpectedDatabase(value = > > > >> > "extra_and_default_category-expected.xml", > > > >> > assertionMode = DatabaseAssertionMode.NON_STRICT_UNORDERED) > > > >> > > > > >> > > > > >> > More information is available at: > > > >> > > > > >> > http://lbitonti.github.io/deltaspike-dbunit/ > > > >> > https://github.com/lbitonti/deltaspike-dbunit > > > >> > > > > >> > > > > >> > It's essentially a port of springtest-dbunit, for those familiar > > > >> > with > > > >> it, > > > >> > to cdi/deltaspike. > > > >> > Hopefully it will be useful to other people as well. Feedback > > > welcome. > > > >> > > > > >> > Cheers, > > > >> > Luigi > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > > <http://www.advancedit.com.br/>Att, > > > > > > > > Rafael M. Pestano > > > > > > > > Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do > > > Sul > > > > http://rpestano.wordpress.com/ @realpestano > > > > <https://twitter.com/realpestano> > > > > > > > > > > > > > > > > -- > > > <http://www.advancedit.com.br/>Att, > > > > > > Rafael M. Pestano > > > > > > Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul > > > http://rpestano.wordpress.com/ @realpestano > > > <https://twitter.com/realpestano> > > > -- <http://www.advancedit.com.br/>Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul http://rpestano.wordpress.com/ @realpestano <https://twitter.com/realpestano>
