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