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