Feature: Validate and/or update HAR recording against server

[markwhitfeld]

Description

Thank you for the awesome library.
One thing that I would love to be able to do, is check the recorded responses against the server and potentially update them without having to run my test/client code to do it.

This would allow for a sort of "Contract testing" (I am aware of the other open issue #351 , but that issue seems to be quite a general request with no specific use case or proposal).
The envisaged workflow:

• [Client side team] Uses PollyJs as directed in the docs to record a HAR snaphost file from the client test suite.
• [Client side team] Include the HAR file in version control so that the tests can run against the recorded responses in CI.
• [Server side team] A separate process can be used to validate that the HAR file matches the latest responses from the server.
  • VALIDATION: For example, another team can consume the HAR file (which represents the expectations - or 'contract' - that the client side team has for the server) and run it as part of their testing process to ensure that they are not breaking expectations.
  • UPDATE: If something has changed and they would like to update the HAR file to send back to the client team, then conceivably they could run a command (cli or API) which will output the updated HAR file (overwrite, or new file). This updated file could be sent to the client team for comparison or just as a new baseline that they can run their tests against to check if their client side code works with the new responses or if it needs to be updated.
  • [Both teams] smiling because they know that any regressions will be picked up as early as possible!

Potentially this functionality could be implemented as a separate lib/adapter/reorder combination... unless something like this already exists?

Advanced considerations (not MVP):

• The server side team may need to be able to substitute urls and modify the request to run the HAR file validation against various environments. This would potentially need to be part of this api.

Alternative considerations:

• The lib could provide a way of iterating through the pairs of request/responses in the har file. This could be used to dynamically create test cases for each of the requests.
  • The RecordedRequest could have a resend(overrideOptions): Response method as well as a way to access each of the properties for the data stored in the HAR entry.
  • The RecordedResponse could have a matches(response: Response, matcherOptions): MatchResult method as well as a way to access each of the properties for the data stored in the HAR entry. This result could be checked in the test through inspection, or by providing a test framework compatible matcher.