Thx Claus, I think that's really good to have separated the spring stuff as it will allow blueprint users to not depend on spring at all at testing.
Btw, I mentioned some time ago integration tests for archetypes, so here's a pointer: https://github.com/apache/karaf/blob/trunk/archetypes/itests/src/test/java/org/apache/karaf/archetypes/AbstractArchetypeTest.java On Wed, Jan 25, 2012 at 08:59, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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/ -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
