I suggest to read the testing page and start tests with only mock
endpoints first.
Look at some of the examples and how they may have unit tests
And consider buy one of the Camel books that covers Camel in much better details
On Thu, Oct 27, 2016 at 2:03 PM, Edoardo Causarano
I don’t think DataSet is going to do what you’re after.
You could try a mock endpoint, and use returnReplyBody(…) to specify the
response - that may do what you’re after
> On Oct 28, 2016, at 1:18 AM, Edoardo Causarano
> wrote:
>
> Hi Quinn,
>
> Thanks that's
Hi Quinn,
Thanks that's correct, but really I was looking for a way to test the
construct timer+broadcast+pipelines+merged_processor.
Shoving the datasets to fake the remotes inside the pipelines made sense.
Anyway, I'll see if I have time to get back to this setup sometime later.
Right now I'm
I’m assuming you’re just trying to get the DataSet to work for testing -
correct? (DataSet isn’t really meant for anything other than testing).
If that’s the case, use the DataSet as the Consumer - i.e.
from(“dataset://source”) and you should be OK.
> On Oct 27, 2016, at 7:15 AM, Edoardo
Hi,
answers inline:
> On 27 Oct 2016, at 14:50, Brad Johnson wrote:
>
> Try putting in .log(${body}) in between each of the lines and see what you
> get. It appears you are using the SimpleDataSet which takes a single
> String. What behavior are you expecting
Try putting in .log(${body}) in between each of the lines and see what you
get. It appears you are using the SimpleDataSet which takes a single
String. What behavior are you expecting from ti? Is it throwing an
exception? Have you tried sending in a List with a ListDataSet to
see what behavior
Hi all,
I’m trying to do something relatively simple, yet it’s been eluding me for
hours already!
I’d like to have a timer trigger a broadcast to a couple pipelines to invoke a
remote cloud component, transform the responses to a common type and merge the
results in one homogenous list to