Akka.TestKit's "ExpectMsgAllOf" methods could be emulated to provide new Predicate-based testing methods.

[malclear]

Problem

I’ve been running into issues with tests failing periodically in the Akkatecture library I maintain. Looking back, I see that the issue has existed for a while; the original Akkatecture author made note of it. Essentially, the tests are racy, “Heisenbug”-style problems.

While looking for a solution, I see Akka.TestKit has a set of ExpectMsgAllOf methods that can be used for "expecting" a set of messages. It is described as a solution to racy tests here: Debugging Akka.NET. I would like to use something like this to test for a set of events that should exist after a specific domain action. However, aspects of the ExpectMsgAllOf methods make them unsuitable for the purpose:

1. They require whole objects to be submitted for an equality check, rather than allowing Predicates (as does the ExpectMsg functions).
   1. If the contents of the events resulting from the test are not easily predicted, then using a Predicate to validate individual aspects of each message might suffice.
   2. I'm unable to supply our own value to the parameter areEqual, as it exists only in the private method InternalExpectMsgAllOfAsync<T>(...) (and that would be hackish anyway).
2. The ExpectMsgAllOf method expects a common message type, T.
   1. In my use-case, events will be a variety of types, all derived from a common ancestor, and the details of the derived type would be required to satisfy the Predicate associated with the particular message.

Proposed Solution

I propose a set of methods named as ExpectMsgAllOfWithPredicates that would allow setting the expectations for sets of messages using predicates. This would be similar to how the ExpectMsg methods accept Predicate<T> as a parameter.

To enable heterogeneous message types in the set, the methods would accept a collection of a new type, PredicateInfo, that would contain the type of the expected input as an instance of Type.

The wrapper class PredicateInfo would have only two properties of the types Delegate and Type. Static helper methods will be supplied as factories for safety and convenience.

[Aaronontheweb]

closed via #6668