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<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/
