camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" <>
Subject Re: ContextTestSupport
Date Sat, 29 Nov 2008 07:48:53 GMT

Actually I would love the we also supported the non bleeding edge
developers that are *not* using Guice, Hamcrest and spring testing.

I really understand Martins use-cases with rapid unit testing and
having it all in a simple plain java file. I am not to keen on the
java + spring xml for unit testing as you need two artifacts for this,
and the files are not located in the same folder, so you need to
navigate from src/test/java/.... to the same folder in
src/test/resources. I know IDE support can help here but sometimes you
actually browse using a plain text editor.

So if CamelContextSupport or some other easy going can be used for
easy plain old junit 3.8 testing in a single file then, and easy for
end users to use then that has a big +1 for me

/Claus Ibsen
Apache Camel Committer

On Fri, Nov 28, 2008 at 12:11 PM, James Strachan
<> wrote:
> 2008/11/28 Martin Gilday <>:
>> --- 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?
> --
> James
> -------
> Open Source Integration

View raw message