You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2012/01/24 10:15:51 UTC
[DISCUSS] - Add camel-test-spring component
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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <cl...@gmail.com> wrote:
> On Tue, Jan 24, 2012 at 4:36 PM, Hadrian Zbarcea <hz...@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<hz...@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
>>>>> <ch...@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<cl...@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
Re: [DISCUSS] - Add camel-test-spring component
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 24, 2012 at 4:36 PM, Hadrian Zbarcea <hz...@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<hz...@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
>>>> <ch...@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<cl...@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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jan 25, 2012 at 12:08 AM, Christian Müller
<ch...@gmail.com> wrote:
> I like this improvement. This is the right way, IMO.
Yeah let me create a JIRA ticket so we capture this.
> I also share the opinion from Hadrian about the CamelSpringTestSupport.
> It's great for our users (I'm also one of them :-) ) to test their routes.
> And we need of course a few tests to make sure it works. We may need a few
> more tests which have more an example character to demonstrate the XML DSL
> for our users. But in general, most of our tests should "only" use the
> CamelTestSupport.
Yeah me to as well. Most components should be fine using the plain
CamelTestSupport.
However a few could be using CamelSpringTestSupport in the nature of
being examples.
Many people ask how to do X with Camel and either want a Java based or
XML based example.
Also when people contribute components to Apache Camel, then they may
write unit tests
which are more Spring XML favored than plain Java based. So we cannot
control this.
However by removing the Spring pieces from camel-test, we may be able
to have a better overview
of which components that uses CamelSpringTestSupport, as they would
not compile anymore :)
> As already mentioned, after I resolved the issues I'm working on, I will
> have a look at our unit tests.
>
> Best,
> Christian
>
> On Tue, Jan 24, 2012 at 10:07 PM, Hadrian Zbarcea <hz...@gmail.com>wrote:
>
>> Revision [3] is just the tip of the iceberg. There were other before
>> mostly related to using dynamic ports and proper cleanup that allowed the
>> forkMode='once'. One of the other components that would greatly benefit
>> from that is camel-jms.
>>
>> On the hanging test on Windows, that's obviously an issue that has to be
>> resolved and has little to do with the improvements I mentioned. My only
>> Windows system is an Atom based netbook which I rarely use, I cannot
>> confirm or deny experiencing that. Christian and Willem are usually pretty
>> fast at resolving Windows issues.
>>
>> Speaking of CI and jenkins, I don't know of any asf project that takes
>> that long to test and sucks so many resources. Fwiw, that's one of the
>> improvements on my agenda for 3.0.
>>
>> Cheers,
>> Hadrian
>>
>>
>>
>>
>> On 01/24/2012 11:03 AM, Babak Vahdat wrote:
>>
>>> Hadrian,
>>>
>>> you mentioned a really good point regarding the improvements by camel-cxf
>>> testing that I intended to bring into the discussion for today anyway:
>>>
>>> Last night I was looking at my monitor as the full build on Windows (build
>>> 216) was running and was really stumped as the test:
>>>
>>> org.apache.camel.component.**cxf.cxfbean.CxfBeanTest
>>>
>>> Was running, running and running again [1] for exactly 365 minutes, that's
>>> more than 6 hours!
>>>
>>> At the last Jenkins killed the build process and now I assume because of
>>> that (and maybe some other reasons as well) we're banned from the build on
>>> Windows due to previous failure(s) [2].
>>>
>>> I assume your mentioned revisions like [3] by your post.
>>>
>>> [1] https://builds.apache.org/job/**Camel.trunk.fulltest.windows/**
>>> 216/console<https://builds.apache.org/job/Camel.trunk.fulltest.windows/216/console>
>>> [2] https://builds.apache.org/job/**Camel.trunk.fulltest.windows/**
>>> 217/console<https://builds.apache.org/job/Camel.trunk.fulltest.windows/217/console>
>>> [3] http://svn.apache.org/viewvc?**view=revision&revision=1151313<http://svn.apache.org/viewvc?view=revision&revision=1151313>
>>>
>>> Babak
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.**
>>> com/DISCUSS-Add-camel-test-**spring-component-**tp5281207p5294755.html<http://camel.465427.n5.nabble.com/DISCUSS-Add-camel-test-spring-component-tp5281207p5294755.html>
>>> Sent from the Camel Development mailing list archive at Nabble.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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Christian Müller <ch...@gmail.com>.
I like this improvement. This is the right way, IMO.
I also share the opinion from Hadrian about the CamelSpringTestSupport.
It's great for our users (I'm also one of them :-) ) to test their routes.
And we need of course a few tests to make sure it works. We may need a few
more tests which have more an example character to demonstrate the XML DSL
for our users. But in general, most of our tests should "only" use the
CamelTestSupport.
As already mentioned, after I resolved the issues I'm working on, I will
have a look at our unit tests.
Best,
Christian
On Tue, Jan 24, 2012 at 10:07 PM, Hadrian Zbarcea <hz...@gmail.com>wrote:
> Revision [3] is just the tip of the iceberg. There were other before
> mostly related to using dynamic ports and proper cleanup that allowed the
> forkMode='once'. One of the other components that would greatly benefit
> from that is camel-jms.
>
> On the hanging test on Windows, that's obviously an issue that has to be
> resolved and has little to do with the improvements I mentioned. My only
> Windows system is an Atom based netbook which I rarely use, I cannot
> confirm or deny experiencing that. Christian and Willem are usually pretty
> fast at resolving Windows issues.
>
> Speaking of CI and jenkins, I don't know of any asf project that takes
> that long to test and sucks so many resources. Fwiw, that's one of the
> improvements on my agenda for 3.0.
>
> Cheers,
> Hadrian
>
>
>
>
> On 01/24/2012 11:03 AM, Babak Vahdat wrote:
>
>> Hadrian,
>>
>> you mentioned a really good point regarding the improvements by camel-cxf
>> testing that I intended to bring into the discussion for today anyway:
>>
>> Last night I was looking at my monitor as the full build on Windows (build
>> 216) was running and was really stumped as the test:
>>
>> org.apache.camel.component.**cxf.cxfbean.CxfBeanTest
>>
>> Was running, running and running again [1] for exactly 365 minutes, that's
>> more than 6 hours!
>>
>> At the last Jenkins killed the build process and now I assume because of
>> that (and maybe some other reasons as well) we're banned from the build on
>> Windows due to previous failure(s) [2].
>>
>> I assume your mentioned revisions like [3] by your post.
>>
>> [1] https://builds.apache.org/job/**Camel.trunk.fulltest.windows/**
>> 216/console<https://builds.apache.org/job/Camel.trunk.fulltest.windows/216/console>
>> [2] https://builds.apache.org/job/**Camel.trunk.fulltest.windows/**
>> 217/console<https://builds.apache.org/job/Camel.trunk.fulltest.windows/217/console>
>> [3] http://svn.apache.org/viewvc?**view=revision&revision=1151313<http://svn.apache.org/viewvc?view=revision&revision=1151313>
>>
>> Babak
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.**
>> com/DISCUSS-Add-camel-test-**spring-component-**tp5281207p5294755.html<http://camel.465427.n5.nabble.com/DISCUSS-Add-camel-test-spring-component-tp5281207p5294755.html>
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>
> --
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/
>
Re: [DISCUSS] - Add camel-test-spring component
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Revision [3] is just the tip of the iceberg. There were other before
mostly related to using dynamic ports and proper cleanup that allowed
the forkMode='once'. One of the other components that would greatly
benefit from that is camel-jms.
On the hanging test on Windows, that's obviously an issue that has to be
resolved and has little to do with the improvements I mentioned. My only
Windows system is an Atom based netbook which I rarely use, I cannot
confirm or deny experiencing that. Christian and Willem are usually
pretty fast at resolving Windows issues.
Speaking of CI and jenkins, I don't know of any asf project that takes
that long to test and sucks so many resources. Fwiw, that's one of the
improvements on my agenda for 3.0.
Cheers,
Hadrian
On 01/24/2012 11:03 AM, Babak Vahdat wrote:
> Hadrian,
>
> you mentioned a really good point regarding the improvements by camel-cxf
> testing that I intended to bring into the discussion for today anyway:
>
> Last night I was looking at my monitor as the full build on Windows (build
> 216) was running and was really stumped as the test:
>
> org.apache.camel.component.cxf.cxfbean.CxfBeanTest
>
> Was running, running and running again [1] for exactly 365 minutes, that's
> more than 6 hours!
>
> At the last Jenkins killed the build process and now I assume because of
> that (and maybe some other reasons as well) we're banned from the build on
> Windows due to previous failure(s) [2].
>
> I assume your mentioned revisions like [3] by your post.
>
> [1] https://builds.apache.org/job/Camel.trunk.fulltest.windows/216/console
> [2] https://builds.apache.org/job/Camel.trunk.fulltest.windows/217/console
> [3] http://svn.apache.org/viewvc?view=revision&revision=1151313
>
> Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Add-camel-test-spring-component-tp5281207p5294755.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hadrian,
you mentioned a really good point regarding the improvements by camel-cxf
testing that I intended to bring into the discussion for today anyway:
Last night I was looking at my monitor as the full build on Windows (build
216) was running and was really stumped as the test:
org.apache.camel.component.cxf.cxfbean.CxfBeanTest
Was running, running and running again [1] for exactly 365 minutes, that's
more than 6 hours!
At the last Jenkins killed the build process and now I assume because of
that (and maybe some other reasons as well) we're banned from the build on
Windows due to previous failure(s) [2].
I assume your mentioned revisions like [3] by your post.
[1] https://builds.apache.org/job/Camel.trunk.fulltest.windows/216/console
[2] https://builds.apache.org/job/Camel.trunk.fulltest.windows/217/console
[3] http://svn.apache.org/viewvc?view=revision&revision=1151313
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Add-camel-test-spring-component-tp5281207p5294755.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] - Add camel-test-spring component
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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<hz...@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
>>> <ch...@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<cl...@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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 24, 2012 at 4:09 PM, Hadrian Zbarcea <hz...@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
>> <ch...@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<cl...@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/
--
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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Actully, imo, a camel-test-spring should only be used for integration
and by users, not for unit tests.
Hadrian
On 01/24/2012 06:16 AM, Claus Ibsen wrote:
> On Tue, Jan 24, 2012 at 11:59 AM, Christian Müller
> <ch...@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<cl...@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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 24, 2012 at 11:59 AM, Christian Müller
<ch...@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 <cl...@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/
>>
--
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/
Re: [DISCUSS] - Add camel-test-spring component
Posted by Christian Müller <ch...@gmail.com>.
In generall a good idea. But I doesn't like to lose the possibilities to
use the annotations like @EnpointInject, ...
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 <cl...@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/
>