We often test via spec scripts to verify implementation behavior instead of tightly coupled unit tests.
The intent is to be able to refactor the code, but still have stable tests to verify new implementation. Tightly coupled tests are typically forced to change when the code is refactored, preventing the stable basis to verify consistency.

Let's discuss further over Slack community as needed on this feedback.

So you can use route.identity(guard, authorization) from MqttConditionMatcher constructor (see below).

Add Map<String, LongFunction<String>> identities private field and populate in constructor.

Add String identity(String guard, long authorization) to MqttRouteConfig.

String identity(
    String guard,
    long authorization)
{
    return identities.getOrDefault(guard, a -> null).apply(authorization);
}

Done, thanks!

I am reopening this because this caused a bug while I was applying the last suggestions to the PR:

When we pass this to the MqttConditionMatcher constructor, it receives an instance of MqttRouteConfig that is not completely initialized yet. This might produce unexpected behaviour when accessing uninitialized MqttRouteConfig fields inside the MqttConditionMatcher constructor.

In this specific case, the MqttConditionMatcher constructor calls the route.identity() method, but the route.identities field is not yet initialized at this time, and this produces a NullPointerException.

To solve this I moved the when field initialization at the bottom of the MqttRouteConfig constructor, so that all the other fields are initialized when calling the MqttConditionMatcher constructor with this as an input. But this still feels kind of wierd, so maybe it is better to pass the route.identities field to the MqttConditionMatcher constructor, rather than the whole MqttRouteConfig object which is not fully initialized? 🤔

Let me know!