Hi 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 Blog: http://davsclaus.blogspot.com/ On Fri, Nov 28, 2008 at 12:11 PM, James Strachan <[EMAIL PROTECTED]> wrote: > 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? > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ >
