Mock objects came about because people were sick of doing dummy objects.
Dummy objects aren't flexible enough
Sent from tablet device. Please excuse typos and brevity.
On Jul 1, 2012 12:43 PM, "Christian Müller" <christian.muel...@gmail.com>
wrote:
> A much more simpler approach from my point of view is providing a dummy
> "MyProcessor" in the registry (Simple or Spring based). Than you can test
> your route logic in isolation without testing (again) your "MyProcessor".
> And it's much more light weigh than using EasyMock...
>
> Best,
> Christian
>
> On Sun, Jul 1, 2012 at 9:44 AM, gilboy <josephoto...@gmail.com> wrote:
>
> > Hi
> >
> > I have a route which looks like:
> >
> >
> >
> from("MyEndpoint").to("bean:MyProcessor").choice().when(*header("HeaderField").equals("Field1")*).....when(*header("HeaderField").equals("Field2")*)
> >
> > The bean MyProcessor sets the "HeaderField". In my camel junit test
> class I
> > load this exsting route. I would like to mock the behavior of
> MyProcessor.
> > For my first test I would want it to return Field1 and for my second
> test I
> > would want it to return Field2 to ensure I hit both flows coming from the
> > content-based router.
> >
> > Typically I would use EasyMock for this. Is there any problems in using
> > EasyMock with the Camel JUnit extensions? Does Camel provide another
> > approach for this problem?
> >
> > Thanks
> >
> >
> >
> > --
> > View this message in context:
> >
> http://camel.465427.n5.nabble.com/Camel-JUnit-Extensions-EasyMock-tp5715330.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
