Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 209.85.213.45 as permitted sender)
Message-ID: <4F1ECFEE.2040105@gmail.com>
Date: Tue, 24 Jan 2012 10:36:14 -0500
From: Hadrian Zbarcea <hzbarcea@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [DISCUSS] - Add camel-test-spring component
References: 
 <CAGB5yNkWM0uTJxzvSznev7eE=hC-HDGF_dAdOYD3zgs_t1Szcw@mail.gmail.com>
 <CALvzYd98D2wNLbgXMV-4e300k1Eg0ouWjUNcbyVjXeePmf01mg@mail.gmail.com>
 <CAGB5yNn2mzb-6E_eCv1WPiax_VNcQ_CGO_oinkGfGHpO4-YP1A@mail.gmail.com>
 <4F1EC9B0.6050503@gmail.com>
 <CAGB5yNnFzOQtGrD9h+X53TUngALhiuo-Nu_GRT_R+e02mDgBWg@mail.gmail.com>
In-Reply-To: 
 <CAGB5yNnFzOQtGrD9h+X53TUngALhiuo-Nu_GRT_R+e02mDgBWg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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).

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/