You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by gilboy <jo...@gmail.com> on 2012/07/01 09:44:36 UTC
Camel JUnit Extensions + EasyMock
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.
Re: Camel JUnit Extensions + EasyMock
Posted by James Carman <jc...@carmanconsulting.com>.
There are times when your route needs to call a service of some sort. This
is when I use mock objects.
On Jul 2, 2012 5:06 AM, "Henryk Konsek" <he...@gmail.com> wrote:
> Hi all,
>
> > 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?
>
> Of course you can add mocked bean into registry. It will work like a
> charm with EasyMock, Mockito and so forth.
>
> SimpleRegistry registry = new SimpleRegistry();
> registry.put("MyProcessor", EasyMock.createMock(MyProcessor.class));
> CamelContext context = new DefaultCamelContext(registry);
>
> But I'll personally prefer to stick to more module way of testing my
> routes:
>
> 1) Test Processor in separated Unit test.
>
> 2) Model your production routes to use Direct [1] endpoints:
>
> from("MyEndpoint").to("direct:process");
>
> from("direct:process").to("bean:MyProcessor").to("direct:route");
>
> from("direct:route").choice() ...
> when(header("header").equals("foo)).
> to("direct:fooChoice") ...
>
> 3) add Mock [2] endpoints to your tests:
>
> from("direct:fooChoice").to("mock:fooChoice");
>
> 3) Then test headers values directly:
>
> @Test
> public void shouldRouteToFoo() {
> // Given
> String message = "message";
>
> // When
> template.sendBodyAndHeader("direct:route", "header", "foo", message);
>
> // Then
> MockEndpoint endpoint = getMockEndpoint("mock:fooChoice");
> // make some assertions on mock endpoint here
> }
>
> This approach is much more maintainable for large applications.
> Putting mocks onto monolithic routes leads to cluttered routing test
> code. This is just my opinion of course - based on my experience, not
> on official Camel guidelines.
>
> Best regards.
>
> [1] http://camel.apache.org/direct.html
> [2] http://camel.apache.org/mock.html
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Re: Camel JUnit Extensions + EasyMock
Posted by Henryk Konsek <he...@gmail.com>.
Hi all,
> 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?
Of course you can add mocked bean into registry. It will work like a
charm with EasyMock, Mockito and so forth.
SimpleRegistry registry = new SimpleRegistry();
registry.put("MyProcessor", EasyMock.createMock(MyProcessor.class));
CamelContext context = new DefaultCamelContext(registry);
But I'll personally prefer to stick to more module way of testing my routes:
1) Test Processor in separated Unit test.
2) Model your production routes to use Direct [1] endpoints:
from("MyEndpoint").to("direct:process");
from("direct:process").to("bean:MyProcessor").to("direct:route");
from("direct:route").choice() ...
when(header("header").equals("foo)).
to("direct:fooChoice") ...
3) add Mock [2] endpoints to your tests:
from("direct:fooChoice").to("mock:fooChoice");
3) Then test headers values directly:
@Test
public void shouldRouteToFoo() {
// Given
String message = "message";
// When
template.sendBodyAndHeader("direct:route", "header", "foo", message);
// Then
MockEndpoint endpoint = getMockEndpoint("mock:fooChoice");
// make some assertions on mock endpoint here
}
This approach is much more maintainable for large applications.
Putting mocks onto monolithic routes leads to cluttered routing test
code. This is just my opinion of course - based on my experience, not
on official Camel guidelines.
Best regards.
[1] http://camel.apache.org/direct.html
[2] http://camel.apache.org/mock.html
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Camel JUnit Extensions + EasyMock
Posted by James Carman <jc...@carmanconsulting.com>.
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" <ch...@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 <jo...@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.
> >
>
Re: Camel JUnit Extensions + EasyMock
Posted by Willem Jiang <wi...@gmail.com>.
+1 for the dummy processor.
But I think using the EasyMock can set the behavior of the message
which will be used to verify the choice processor.
On Mon Jul 2 00:43:27 2012, Christian Müller 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 <jo...@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.
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel JUnit Extensions + EasyMock
Posted by Christian Müller <ch...@gmail.com>.
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 <jo...@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.
>
Re: Camel JUnit Extensions + EasyMock
Posted by James Carman <ja...@carmanconsulting.com>.
You can use EasyMock, you just have to add your mock objects to the
"registry." Works like a charm. You do have to do some gymnastics
with your route builder test superclass to get all the syntactic sugar
you get with EasyMock. You can refer to this code if you want:
https://github.com/jwcarman/smx-example/blob/master/camel/src/test/java/com/carmanconsulting/smx/example/camel/route/AbstractRouteBuilderTest.java
On Sun, Jul 1, 2012 at 3:44 AM, gilboy <jo...@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.