camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] - Add camel-test-spring component
Date Wed, 25 Jan 2012 08:41:48 GMT
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.ibsen@gmail.com> wrote:
> On Tue, Jan 24, 2012 at 4:36 PM, Hadrian Zbarcea <hzbarcea@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<hzbarcea@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.mueller@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.ibsen@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: cibsen@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: cibsen@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

Mime
View raw message