On Thu, Sep 20, 2012 at 10:00 AM, pmcb55 <[email protected]> wrote:
> Hi Claus,
>
> I don't think your idea will work for me. In my example above I did
> statically list all the query parameter combinations, but in my real code
> they are generated dynamically. So really my route looks more like:
>
>   from("direct:start").process(new
> ClassThatGeneratesDynamicUriHeader()).recipientList(header("DynamicURI"));
>
> The 'ClassThatGeneratesDynamicUriHeader' simply builds the full URI for the
> recipient list to invoke on - the real code will have a URI starting with
> 'http://www.theRealService.com/', whereas my unit tests will have a URI
> starting with 'mock:MockedService' - and both will have the various query
> parameters appended to the URI (i.e.
> 'mock:MockedService?q=searchTerm&UserPriority=High').
>
> So that is why I want to simply write...:
>
>   Processor emulator = new EmulatorThatActsLikeTheComplexHttpService();
>   MockEndpoint mock = getMockEndpoint("mock:Service***");
>   mock.whenAnyExchangeReceived(emulator);
>
> ...to have my emulator called for all calls to the mock service endpoint
> with the numerous query parameter combinations (i.e. I specifically don't
> want to have to pre-define all those combinations and register a
> 'whenAnyExchangeReceived()' call for each of them - I just want to wildcard
> that registration!).
>
> Maybe people just don't work with dynamically generated Http URI's that
> much! I know I can get this working with a simple 'adviceWith()' construct
> (since that does allow endpoints to be 'wildcarded'), I just thought the
> above 3 lines of code would be more intuitive and easy for people).
>

Yeah use advice with and the likes. Thats what its for.

The API on MockEndpoint is for a *single* endpoint. It would be
confusing if some of the methods
would apply for N+ endpoints, and others only on a single endpoint.
Also the internal implementation is based on a single mock.


What you would need is a MockEndpoints, eg for plural. And a
designated API that work for N+ endpoints.
And supporting some wildcard matching to more easily configure which
mocks it applies for.



>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-mock-endpoints-taking-lots-of-different-query-parameters-values-tp5719629p5719649.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Reply via email to