Hi, I don’t think you need to use mock framework to mock the bean. You can just write a simple bean which implement the bean’s interface to setup the message headers and exchange properties for you camel route.
-- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On December 30, 2013 at 4:36:53 PM, Stephan Burkard (sburk...@gmail.com) wrote: > > Hi Camel users > > To process arbitrary logic in my Camel routes, I use simple bean > calls. > That is fine because I can test all these pieces of logic with standard > unit tests. > > However, often the bean calls produce results that are saved > in the message > header (if I need to save it for later) or Exchange properties > (if it is > only needed in the current route). > > So my bean methods often look like this: > public void setDocumentGuid(@Headers Map > headers); > > The header-map is passed to add new headers, the method is simply > called > with "bean(bean, method)" in the route. > > My problem arised in the route tests where I mock away the whole > bean. I > can mock the method call, but I cannot add entries to the header- > or > property-maps. So if the header or property entry is expected > later in the > route, it fails. > > Therefore I moved to bean methods like this: > public String setDocumentGuid(); > > The header-map is no more needed, since the header value is returned > and > the method is called with "setHeader(headerKey, bean(bean, > method)" in the > route. Now I can return whatever I like from the mock. > > But the problem returns if > > #1: I have multiple values or objects I would like to save. I cannot > return > them in the method (without creating a "transport object" or > returning a > map), so I need to add them to the headers or properties in the method, > but > then they are not existing when I mock the method call. > > #2: I would like to test a subroutes (direct:) that is expecting > Exchange > properties from the parent route. I cannot easily set these properties > for > the tests of the subroute (I probably could by injecting a processor > for > the test that sets them, but the most simple test would become > quite > complex). > > I would like to only test the correct message flow with route tests > and > therefore mock away all beans (that are already tested with unit-tests), > but since my beans set message headers or properties they are > like a > route-extension and needed to execute the route correctly. > > Am I missing a basic Camel concept? How do you draw the line between > route > with headers/properties and "external" components like beans? > > Thanks for any help > Stephan >