camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <>
Subject [jira] Commented: (CAMEL-327) implement mock testing using a new Endpoint which grabs the expected messages from another endpoint
Date Mon, 11 Feb 2008 16:54:42 GMT


James Strachan commented on CAMEL-327:

Yeah good point :) I guess we'd hope that the route to the expects endpoint was fast; I wonder
if we need some way to say that its 'finished'.

Or maybe we use a kinda modified mock endpoint where input messages are stashed away in a
List; then as the expectations arrive they are added to already received messages - or are
stashed away for the future or something. i.e. coding the endpoint so that the actual and
expected messages could arrive in any order. The only real timeout being that the expectations
are met within some timeout value (for both actual and expects messages to be received).

> implement mock testing using a new Endpoint which grabs the expected messages from another
> ---------------------------------------------------------------------------------------------------
>                 Key: CAMEL-327
>                 URL:
>             Project: Apache Camel
>          Issue Type: New Feature
>            Reporter: James Strachan
>            Assignee: Hadrian Zbarcea
>            Priority: Critical
>             Fix For: 1.3.0
> e.g. it'd be nice to be able to write a test case as something like...
> {code}
> from("something").to("mock:file://src/test/data");
> {code}
> Where the mock endpoint is smart enough to spot that its name is a URI - in which case
it basically consumes messages from that URI and for each message it receives, it uses that
as another assertion on the actual mock endpoint.
> i.e. we can use a directory of expected messages as the assertion statements in a test
> We might want to support some kinda XML message payload, so that we can make assertions
on what kinda headers and payloads we expect on the messages. Or maybe we just have some kinda
transform in between to strip out any headers we don't care about. Something like...
> {code}
> from("something").bean(RemoveSomeHeaders.class).to("mock:file://src/test/data");
> {code}

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message