The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

OrBee (61) [Avatar] Offline
#1
<test:component> some clarification
I read chapter 12 like you suggested but as far as the explanation of the specific purpose of it being used in the context <test:component/> in testing flows I am a little foggy.

I do understand it's use in returning data, throwing exceptions etc. but it is when it is used like <test:component/> that I don't get.

Does it simply capture output from the flow like an endpoint? If it does, how can it be referenced in a test since it is not given any specific reference in the flow? Under what conditions would one use it instead of a regular outbound endpoint? Does it work in request-response test scenarios as well as in one-way tests? If all it does is capture output should one not simply use a regular outbound endpoint?
David Dossot (233) [Avatar] Offline
#2
Re: &lt;test:component&gt; some clarification
> Does it simply capture output from the flow like an endpoint?

In essence, yes.

> If it does, how can it be referenced in a test since it is not given any specific reference in the flow?

Use "getFunctionalTestComponent" from the parent class, see: https://github.com/ddossot/mule-in-action-2e/blob/master/chapter12/src/test/java/com/muleinaction/AcmeApiBridgeImprovedTestCase.java#L42

> Under what conditions would one use it instead of a regular outbound endpoint?

The test:component doesn't dispatch messages so you can't really use one for another. You use the test:component in test flows only, not production flows, for example to stub out a remote service, to simulate failures or to capture the payload at some point in a flow.

> Does it work in request-response test scenarios as well as in one-way tests?

Yes, it is unaware of the current event exchange pattern.

> If all it does is capture output should one not simply use a regular outbound endpoint?

I reckon you mean a "VM outbound endpoint, which you can request from your test for accumulated messages ; otherwise it doesn't make much sense.

But in any case, the semantics are different, especially when it comes to properties: messages accumulated in the VM queue will have only the outbound properties when the outbound endpoint was called, in their inbound scope. If you need deeper inspection, the test:component is your friend.
OrBee (61) [Avatar] Offline
#3
Re: &lt;test:component&gt; some clarification
I looked at the example you showed. The dispatch from the vm queue results in an asychronous event that inserts a row in the database after which the flow proceeds to the http outbound-endpoint. Up to that part is clear. Since the "jdbc://retrieveData" can get the data just inserted, why do we need the return data section of the test component. I really don't understand how this section provides any value in the test. I thought the getFunctionalTestComponent was to get access to the flow itself, since it is called "acmeApiStub". My thought also is that the test component should return
{"result:success"} instead of the results of the "jdbc://retrieveData".
If it simply captures the output why would we need to <test:return-data> portion? Wouldn't that cause it to return {result:success}?
<test:component>
<test:return-data>{"result":"success"}</test:return-data>
</test:component>

The {"result:success"} is not used anywhere in the test and it being there cause me confusion. I'm really sorry, but this is still confusing to me.
OrBee (61) [Avatar] Offline
#4
Re: &lt;test:component&gt; some clarification
i finally get it, but only after reading the online Mule documentation on testin strategies.To date I had only read the book chapter, however reading the documentation really made everything crystal clear.