Phil Derome (40) [Avatar] Offline
#1
Reading Chapter 11 on testing (Jamie Allen), I come under the impression that handling a command (request) from a client and delivering that message to an actor with tell (! method) and then immediately confirming success to client (over Play REST call for example) without waiting for confirmation of acknowledgment message back that the command succeeded in future is an anti-pattern (to reiterate, tell returns Unit whereas ask returns a Future in Scala). I say this because it's saying "you, client, yes, we handled your request, don't worry, it'll succeed even though we'll never get back to you to confirm it does". In other words, it's like basic service of low-priority mail, you just hope client request is delivered. Effectively, I am talking about a asynchronous message protocol with client that is one way and very optimistic (utopian perhaps) as to outcome of commands.

The context is that the initial discussion on testability surrounds always having a response back from the actor receiving the initial message and in some cases we don't have that. I am wondering that using a message protocol that prevents positive confirmation messages back to client is anti-pattern. In the mail metaphor, that means clients should be able to track where their message is at any time or at very least have a "yeah/nay" confirmation message within a bounded time that is possibly long of whether the client's command/request was successful. Also, the examples of Chapter 11 have a response going back to the client and it seems really really crucial to the overall testability. If we don't have a feedback loop, how can we test?

In the capital markets trading world, the protocols such as FIX require an initial feedback or Accept/Reject to handle an order placement and after a possibly optimistic Accept request, it's expected that some error conditions that occur later on would be meaningfully conveyed to the client (but there are such things as "stuck" orders that represent a rather poor client experience, especially when complexity of client order being fragmented among different market places or geographies and a child order encounters a problem).
Phil Derome (40) [Avatar] Offline
#2
Phil Derome wrote:Reading first third of Chapter 11 on testing (Jamie Allen), I come under the impression that handling a command (request) from a client and delivering that message to an actor with tell (! method) and then immediately confirming success to client (over Play REST call for example) without waiting for confirmation of acknowledgment message back that the command succeeded in future is an anti-pattern (to reiterate, tell returns Unit whereas ask returns a Future in Scala). I say this because it's saying "you, client, yes, we handled your request, don't worry, it'll succeed even though we'll never get back to you to confirm it does". In other words, it's like basic service of low-priority mail, you just hope client request is delivered. Effectively, I am talking about a asynchronous message protocol with client that is one way and very optimistic (utopian perhaps) as to outcome of commands.

The context is that the initial discussion on testability surrounds always having a response back from the actor receiving the initial message and in some cases we don't have that. I am wondering that using a message protocol that prevents positive confirmation messages back to client is anti-pattern. In the mail metaphor, that means clients should be able to track where their message is at any time or at very least have a "yeah/nay" confirmation message within a bounded time that is possibly long of whether the client's command/request was successful. Also, the examples of Chapter 11 have a response going back to the client and it seems really really crucial to the overall testability. If we don't have a feedback loop, how can we test?

In the capital markets trading world, the protocols such as FIX require an initial feedback or Accept/Reject to handle an order placement and after a possibly optimistic Accept request, it's expected that some error conditions that occur later on would be meaningfully conveyed to the client (but there are such things as "stuck" orders that represent a rather poor client experience, especially when complexity of client order being fragmented among different market places or geographies and a child order encounters a problem).
Phil Derome (40) [Avatar] Offline
#3
Effectively, I think I can respond myself: this is essentially a mocking question when there is no clean feedback response upstream. The implied side effect for the one direction flow of messages requires verification through normal mocking mechanism. If the downstream dependency is implemented via messaging to a downstream actor, than a Actor mock should work as the authors demonstrate in section 11.3.7, which I had not read when initiating this topic.

In the case where downstream dependency is something else like a web service call, then some web service mock would be required (for example using a RsTestClient as per https://www.playframework.com/documentation/2.5.x/ScalaTestingWebServiceClients).

Here, in 11.3.7, the author(s) explain how to mock a V1 service with TestProbe and verifying the proper receipt of a message (Listing 11.19), which shows how we can mock downstream side effect dependency handled by another actor.
Roland Kuhn (15) [Avatar] Offline
#4
Yes, as you say we agree that whole components are easily mocked when using message-passing.