Hi Claus,
+1 for creating a real camel-test component for Camel 2.0.
If we create a real camel-test component with current Camel modules
layout, it will introduce the cycle dependency into the camel-core
camel-test <--> camel-core
Maybe we could take out the camel-api for the camel-core to resolve this
cycle dependency.
camel-api <-- camel-test <-- camel-core
And there are lots of test cases in the
org.apache.camel.spring.processor package of the camel-spring-test.jar
which extents the test classes in the camel-core-test.jar, it is a
challenge for us to support this kind of code reuseability in the new
camel-test component.
Any thoughts?
Willem
Claus Ibsen wrote:
Hi
I am writing on another tutorial and is showing how to use plain spring test support classes for easier junit testing. And the spring .jars is real jars (not test-jar).
I am thinking that we should for Camel 2.0 also create a real camel-test
component that holds the test support classes end-users and camel itself can
use for unit testing.
Now these test support classes is mixed with the unit test classes themselves.
Then end users can just depend on camel-test in their maven repo and it's a
more elegant. Also the camel-test.jar will not be cluttered with all kind of
leftovers from our unit tests. For instance log4j.properties, jndi.properties
and whatnot we have got have there.
Any thoughts?
I think it's a good idea to get in Camel 2.0 from the start before the API and
what else is locked. Then instead of relying on camel-spring test-jar or
camel-core test-jar then end-users should migrate by switching to camel-test.
Is there any problem if camel-test will support both plain java tests or the spring ones as well?
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
