Http Unit Tests with request bodies are broken

[andradf]

When I found the fix for the problem that was patched in PR #25113, I was surprised to find that the regression wasn't caught by any of the tests. Surely a breaking change to the HTTP request body of a request should be caught. Looking into how the project implements Http unit tests, it seems that HttpMockServer does not validate the request body. Only the url and method are matched against the definitions in the scenario file.

I have a couple of approaches in mind to fix this, but I would like some feedback before diving into making a change that would impact almost every test project.

1. JSON equivalent comparison of method body
   We would compare the actual request body with the body defined in the scenario. Probably with some normalization for whitespace and element order. This should be able take care of deterministic cases, which should cover most cases.
2. Allow for regex comparison on leaf nodes
   If we need to support a non-deterministic request body then a simple solution could be to support defining a regex that a field must match. This complicates the whole object comparison vs option 1 since we can't just compare normalized strings.
3. Validate using JSON schema
   This is probably the most elegant and maintainable solution, but the work required is also far greater than the others as we would have to define a schema for every request body.

[isra-fel]

@andradf thanks for your great suggestion. We had an internal discussion. The two major challenges are:

1. How to actually compare the JSON payload
   • Compare them as strings requires the serialization behavior to be identical, otherwise changing the order of properties can easily be a false positive
   • Compare them as JObjects. This is reliable but requires more engineering effort.
2. How to specify which cases require comparing request payload
   • There are special cases where the request payload can be different every time you run the cmdlet, for example, the resource name can have a random suffix.
   • To address those cases, leverage either a custom C# attribute to mark the case, or a jsonpath or json model to identify which parts of the payload that need to be verified. Whether it's maintainable is another question.