On Tue, Jan 24, 2012 at 4:36 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > Ok, let me clarify, there are a few points made here. Making camel-test > standalone w/o spring dependencies is great, we should do that. Having a > camel-test-spring is ok too and as you mentioned the primary audience for > that would be Spring *users*. The point I was making is that, internally, we > should only use camel-test-spring for integration tests (that's where we > would 'eat our own dog food'), other than that it is not necessary (maybe > with very few exceptions, like jms) and we should use just use camel-test > (w/o spring). >
I committed the new camel-test-spring. And I changed the components to use camel-test-spring which *actually* uses Spring. The commit is here, and we can use that as an overview to see which components uses Spring for testing as well. http://svn.apache.org/viewvc?rev=1235669&view=rev We may be able to cut down on this and remove unnecessary Spring testing if they do not bring much value. It should help on testing time a bit as Spring 3.x is a bit slow to startup/teardown. > As cmueller already mentioned, we badly need to improve the testing time. As > a very notable example, camel-cxf went for being the 4th test time consuming > component (16+ min) to test in a bit over 1 min all thanks to dkulp's > improvements. It's not only adding features that's important. > > Hadrian > > > > On 01/24/2012 10:14 AM, Claus Ibsen wrote: >> >> On Tue, Jan 24, 2012 at 4:09 PM, Hadrian Zbarcea<hzbar...@gmail.com> >> wrote: >>> >>> Actully, imo, a camel-test-spring should only be used for integration and >>> by >>> users, not for unit tests. >>> >> >> Do you mean Camel unit testing itself? Why should we not eat our own dog >> food? >> >> >> camel-test-spring, is for any kind of Camel + Spring testing, whether >> its integration or unit test, etc. >> The test kit, has a base class, CamelSpringTestSupport, that you >> extend, and then make it easier to test. >> Just as we got today. >> >> The proposal is to make the camel-test standalone, so it does not drag >> in Spring JARs, for the growing number >> of people who are not using Spring. And have a camel-test-spring >> component for the Spring users. >> >> >> >>> Hadrian >>> >>> >>> On 01/24/2012 06:16 AM, Claus Ibsen wrote: >>>> >>>> >>>> On Tue, Jan 24, 2012 at 11:59 AM, Christian Müller >>>> <christian.muel...@gmail.com> wrote: >>>>> >>>>> >>>>> In generall a good idea. But I doesn't like to lose the possibilities >>>>> to >>>>> use the annotations like @EnpointInject, ... >>>>> >>>> >>>> https://issues.apache.org/jira/browse/CAMEL-4934 will allow to use the >>>> Camel @EndpointInject annotations in pure Java code (eg no Spring). >>>> I am working on this right now. >>>> >>>> >>>>> One of my bigger intentions for Camel 2.10.0 is to speed up the tests >>>>> (if >>>>> it's possible). In the past we was successful to reduce the time our >>>>> unit >>>>> test needs. At present I don't have a good idea how, but I have a few >>>>> things I will try. >>>>> One of the things I like on the pure Spring test support is the >>>>> "@DirtiesContext" annotation. May we could have simmilar things in >>>>> Camel >>>>> to >>>>> only boot up a new CamelContext if it's needed. >>>>> Another thing is to remove duplicated tests, combine similar tests, use >>>>> plain junit tests where it's possible, ... >>>>> But this is outside auf this thread scope... >>>>> >>>>> Best, >>>>> Christian >>>>> >>>>> On Tue, Jan 24, 2012 at 10:15 AM, Claus Ibsen<claus.ib...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> In the recent work by GNodet to add a new camel-test-blueprint, which >>>>>> I have recently polished. I noticed that the camel-test classes for >>>>>> CamelTestSupport has dependency on Spring JARs. This is not the >>>>>> intent, as there is a CamelSpringTestSupport people should use if they >>>>>> use Spring. >>>>>> >>>>>> So I wonder if it would make sense for us to split camel-test into >>>>>> - camel-test >>>>>> - camel-test-spring >>>>>> >>>>>> eg to move the Spring Test support to a new component. >>>>>> >>>>>> Then we have a vanilla camel-test component that has just dependency >>>>>> on >>>>>> JUnit. >>>>>> This may aid end users, who are not using Spring, that we drag in >>>>>> Spring JARs when they use camel-test. >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Claus Ibsen >>>>>> ----------------- >>>>>> FuseSource >>>>>> Email: cib...@fusesource.com >>>>>> Web: http://fusesource.com >>>>>> Twitter: davsclaus, fusenews >>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>>>> >>>> >>>> >>>> >>> >>> -- >>> Hadrian Zbarcea >>> Principal Software Architect >>> Talend, Inc >>> http://coders.talend.com/ >>> http://camelbot.blogspot.com/ >> >> >> >> > > -- > Hadrian Zbarcea > Principal Software Architect > Talend, Inc > http://coders.talend.com/ > http://camelbot.blogspot.com/ -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
