@Henryk: Yes, that works fine for message headers, I use it a lot to pass expected message headers. But it is not possible for Exchange properties.
@Willem: Yes, that's true. It feels a bit "cumbersome", but it works. Based on your answers, I guess there is no fundamental Camel concept I am missing, but simply the Camel best practices that need to mature in my Camel routes and tests :-) Thanks a lot Stephan On Mon, Dec 30, 2013 at 10:22 AM, Willem Jiang <willem.ji...@gmail.com>wrote: > 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 > > > >
