How can we service test external commands?

[CurlyPaul]

Given serviceA receives an event
And serviceA processes a series of internal events
Then ServiceA produces an external command

how do we monitor this command has been successfully produced in the service tests?

Currently, our test library creates its own subscriber, which is fine for monitoring external events, but as Commands have the SpecificSubscriber property set, the test subscriber will never receive the command, and we cannot verify our service works.

Proposal 1
The external service listens to the synthetic command, and responds with some canned events.

Got problems in here with the DomainUnderTest property having the wrong value, as we are crossing domain boundaries, and also similar problems to the sysnthetic web-api controllers in that that test code for other peoples domains ends up embedded next to our production code.

Proposal 2
We alter PAT to allow a custom or configurable RuleBuilder to be injected. We then leverage that in our service tests so that the test subscriber builds a set of rules in the normal way, except we doesn't have the SpecificSubscriber clauses in there. Thus allowing the test subscriber to receive commands intended for somewhere else.

[DaveAurionix]

Ahh .. good one!

I'm not going to open the debate about whether commands should travel outside the service boundary anyway - I suspect you've had that conversation internally at length already.

Opening up a custom RuleBuilder is a viable option. To me it sounds like we're encouraging application-tier code to know a lot more about the message library inner-workings though. I wonder if we can achieve the same thing with a Boolean eavesdropOnOtherSubscribersForTesting which, if set to true, causes the rule to be built without the SpecificSubscriber restriction (but with a new restriction that the DomainUnderTest condition has to be satisfied - so it avoids confusion in Production if the feature is mis-used and avoids service tests picking up all sorts of sources of those commands - because commands have many senders, one receiver). What do you think?

This is less forwards-compatible than a custom RuleBuilder, but sounds like a simpler scope/problem to solve. Is that better or worse?

Better names for that Boolean almost certainly exist by the way ….

[CurlyPaul]

Yeah that had occurred to me, that injecting a custom rule binder would mean the knowledge of how to build rules starts to bleed into the wrong place. The ability to configure the existing rule binder is much better.

We've talked at great length about the existence of this command yes, not normal practise no but in this case it's an acceptable exception I feel.

[CurlyPaul]

Hello,

I've created a pull request to resolve this, could I please get some reviewers?

#52