Thanks James. One thing I meant to ask about Spring based testing was if you alter your route config for testing or not. We have a Java DSL route file which includes quartz, jms and bean components. If we wanted to unit/integration test this routebuilder config how are you making assertions on it? At the moment we are subclassing the route definition for tests and overriding methods such as getFinalDestinationEndpointUri and changing it from a bean ref to a mock one. We also reduce things like retry delay etc. This seems slightly messy. The wiki page seems to only ever refer to route configs which already have the names of mock endpoints in etc. But I wouldn't think this would naturally be what you have. Do you only ever write route defs for your tests and not test your real 'live' route config?
----- Original message ----- From: "James Strachan" <[EMAIL PROTECTED]> To: [email protected] Date: Wed, 3 Dec 2008 10:14:08 +0000 Subject: Re: ContextTestSupport 2008/12/1 James Strachan <[EMAIL PROTECTED]>: > 2008/11/28 James Strachan <[EMAIL PROTECTED]>: >> 2008/11/28 Martin Gilday <[EMAIL PROTECTED]>: >>> --- I wonder - what is it about the Spring Testing approach that you >>> don't >>> --- like? e.g. you should be able to test out individual routes using >>> this >>> --- approach? >>> >>> I can test out individual routes of the complete route config using that >>> just fine. But when I am writing test cases to demonstrate to >>> colleagues (and myself) how certain Camel components interact with our >>> existing systems loading the whole "live" RouteBuilder is too much. It >>> is nice just to write a specific set of routes just for that test, as >>> Camel commmiters are doing in the test suite. >> >> BTW I started off doing that too - using CamelContextSupport; after a >> while I found it just much cleaner & simpler to just use the Spring >> Testing approach - I find it much cleaner & more elegant. >> >> The downside though is that you need to write 1 test class and 1 XML >> file per test case / demo. >> >> >>> Then in the single file >>> you can see what routes exist, change things to mocks. Otherwise I need >>> to write a seperate Spring config file per test case, and I prefer the >>> Java DSL. I think part of this is becuase at the moment we writing test >>> cases in sort of a TDD design way rather than writing integration tests >>> for a complete system. >> >> I hear you. I prefer using the no-XML approach with the Guice testing >> - then everything is inside a single Java file and much easier to >> navigate/grok. >> >> I might try creating some example tests using the Java Config of >> spring to see if that would suit? > > BTW I raised this JIRA to track this issue... > https://issues.apache.org/activemq/browse/CAMEL-1128 > > I've hacked up an example test case using Spring Test along with > Spring Java Config. The results are similar to using Guice. > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring-javaconfig/ > > e.g. > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring-javaconfig/src/test/java/org/apache/camel/spring/javaconfig/examples/ > > here's the test case > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring-javaconfig/src/test/java/org/apache/camel/spring/javaconfig/examples/FilterTest.java > > the configuration is here > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring-javaconfig/src/test/java/org/apache/camel/spring/javaconfig/examples/FilterConfig.java > > > Unfortunately it doesn't work :( due to a bug where BeanPostProcessors > don't seem to be invoked on test classes > http://jira.springframework.org/browse/SJC-248 This bug is now resolved in trunk of Spring JavaConfig so trunk of Camel's JavaConfig tests now work fine. I'm just gonna spin up another thread to describe the various options now as this is quite a long thread... -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
