[2.35] - mockClient running middlewares which fails matching to the mock store

In PR #168 we added headers to mock strategy. Now I have an issue in 2.35 release that my mocks are no longer matching because of DurationMiddleware running and setting x-started-at to a value that is later unable to be matched in isExactMatch (specifically in the headerMatch):

    {
      A: 'correlation-id=f497e1b8-0fc8-42c5-87e3-5ef58f39bd8e&service-to-service-request=yes&x-started-at=1637663489675',
      B: 'correlation-id=f497e1b8-0fc8-42c5-87e3-5ef58f39bd8e&service-to-service-request=yes&x-started-at=1637663489668'
    }

A workaround is to do a MockDate.set(date) in a beforeEach - which felt a bit random - but without it the Date.now() values will be mismatching and failing to match the correct mock. Mocks not matching have always been a bit hard to debug, and now it is even harder.

This was unexpected though: We do not provide headers, so the test should just work, right?

• Yes, but however, the problem is the fact that mockClient (as per specification!) runs the middleware stack on the mock gateway! This is different to how mockRequest works. So actually, all tests work if switched to mockRequest API instead (without the need for calling MockDate.set(date)).

In summary:

• mockClient runs middlewares which potentially adds headers
• This can cause existing tests to fail (if they are using mockClient) even if they are not providing headers to the mock definition
• #168 was meant to be backwards compatible if your mock definition did not add headers and break if there was mismatch only
• #168 got stabbed in the back by mockClient running middlewares which we were unaware of

Any opinions what we should do, a few options:

• We can proceed, add warnings about the differences mockClient and mockRequest to the README
• We can add best practices about using MockDate.set when running tests (and using DurationMiddleware)
• We can try to make this new behaviour more optional
• We can revert the whole thing

WDYT? Discuss.

[tulios]

I think we can diff the input/output. We could do it for all properties. A bit harder with things like body, but we can still know if a middleware changed it. This change has the potential to improve error messages, etc.

[tulios]

@Yurickh a good idea is to add a canonical way for middleware to add headers, so we can track and differentiate between input headers from userland. I think it’s a good idea.