short addition: imo it's easier/faster to discuss this special topic in our irc channel and post a summary to the list.
@christian: it's quite a long story - so i skipped the details for now to avoid that dan spends a lot of time on it before mark or i have some time to answer your mail properly. regards, gerhard 2012/1/30 Gerhard Petracek <[email protected]> > hi dan, > > thx! if you think about a) or b) mentioned by christian we should discuss > it before you spend a lot of time on it. (because there are/were good > reasons for not doing that.) > > @all: > the only issues i saw (as well): > - right now "moving" resources is broken. e.g. > /META-INF/activation_apache-deltaspike.properties -> > /META-INF/apache-deltaspike.properties for using it just for some tests > doesn't work - and that's what we will need a lot imo. > - the unpack trick is unstable on win, but afaik it works on linux. > > regards, > gerhard > > > > 2012/1/30 Dan Allen <[email protected]> > >> I want to chime in just to let you know that I am looking into >> recommendations for improving the testing structure as well. >> >> I don't have anything concrete yet, and will likely be playing around with >> the suggestions Christian has laid out in addition to whatever comes to my >> mind. I also need to talk to Andrew Rubinger, because he had some very >> valuable suggestions for the JBoss AS testsuite that unfortunately didn't >> get integrated the way he had hoped. Those ideas very likely apply here as >> well. >> >> I'm very interested in finding the right approach for two important >> reasons: >> >> - I'm obviously take great interest in integration testing ;) >> - DeltaSpike will become a role model for how to apply Arquillian, and we >> want to make sure it's the right role model >> >> By all means, continue to write tests. Just know that I do want to be sure >> that the test suite is as friendly, sustainable and useful as possible. >> >> -Dan >> >> On Mon, Jan 30, 2012 at 12:29, Christian Kaltepoth >> <[email protected]>wrote: >> >> > Hey @ all, >> > >> > I want to bring up the integration test structure topic again, >> > especially because discussions regarding new modules are starting. I >> > spent some time on the weekend to work on [1] and while doing this I >> > came to the conclusion that the integration tests currently don't work >> > very well. >> > >> > The main reason for the problems is the fact that the tests are >> > currently split between the core-impl and integration-test modules. >> > Most tests have been added to the core-impl module which contains >> > Arquillian profiles for OWB and Weld. The integration-test module has >> > only a few tests but also unpacks the tests of core-impl and executes >> > them a second time. Beside the profiles for AS7 and Glassfish it also >> > includes the OWB and Weld profiles. I ran into major problems getting >> > the tests to work correctly in both modules mainly due to classpath >> > clashes between different versions of apache-deltaspike.properties on >> > the classpath. >> > >> > I really think we should try to optimize this structure so it runs >> > more smoothly and doesn't execute the tests more than once. IMHO it >> > makes no sense to have Arquillian tests in both core-impl and >> > integration-test. I think we should go with one of the following two >> > ways: >> > >> > A) >> > Move all Arquillian tests from core-impl to the integration-test >> > module so that core-impl only contains standard junit tests. So the >> > integration tests are only executed in the integration-test module. >> > This way we could also remove the OWB and Weld profiles from >> > "parent-code". This structure has the advantage that the >> > integration-test module could simply declare a dependency on the core >> > module JAR which simplifies the Shrinkwrap packaging a lot. >> > >> > B) >> > Move all the Arquillian tests to core-impl. The integration-test >> > module would become dispensable in this case. All unit and integration >> > tests go into the core-impl module and we simply move the AS7 and >> > Glassfish profiles over there (as OWB and Weld are already present). >> > Actually this wouldn't be much work because we would only have to move >> > a few tests and the AS7/Glassfish profiles. Everything else is already >> > there. >> > >> > I for myself would prefer A), but that's just my personal preference. >> > What do you think regarding this? I would love to hear opinions! :) >> > >> > Christian >> > >> > [1] https://issues.apache.org/jira/browse/DELTASPIKE-63 >> > >> > >> > -- >> > Christian Kaltepoth >> > Blog: http://chkal.blogspot.com/ >> > Twitter: http://twitter.com/chkal >> > >> >> >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://google.com/profiles/dan.j.allen >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> > >
