WireMock.Org nullable properties and defaults

[crate-scarter]

Describe the bug

It appears that when using the WireMock.Org.Abstractions to build a request to send to a wiremock/wiremock container, certain fields are present in the Abstractions that aren't required by the API itself. The main example that I saw was the presence of the fromConfiguredStub property on the response when creating a stub. This is a boolean flag that is used to indicate if its the "default, unmatched response, not present otherwise." That field is not required, and so therefore instead of passing the default of the boolean, it probably should be nullable where any null field is simply not sent in the API payload.

Expected behavior:

For fields that are not required to be sent to the API, the fields should probably be nullable in the abstractions to allow for not sending them in the request, which would preserve the default behavior when calling the Wiremock.Org API directly.

public class MappingsResponse {
 // removed properties
 [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
 public bool? FromConfiguredStub {get;set;}
}

This will cause the response sent to the API to not include that field

Test to reproduce

Create a Mapping by setting the WireMock.Org.Abstractions.MappingsRequest and WireMock.Org.Abstractions.MappingsResponse objects.

var request = new Request() {
 Url = "/test",
 Method = "GET"
};

var response = new Response() {
  Status = 200,
  Body = "Test"
  // FromConfiguredStub isn't set here, so it defaults to false
};


var mapping = new  WireMock.Org.Abstractions.Mapping() { Request = request, Response = response};
_httpClient.PostAsJsonAsync("__admin/mappings", mapping);

//make real request to the /test endpoint here will result in a 404

Other related info

I'm using the wiremock/wiremock:3.8.0 container

[StefH]

I can change that field to public bool? FromConfiguredStub { get; set; }.

But it this the only field?

[crate-scarter]

It's hard to say for all of the APIs. I was going through just the insert new stub API method. I think any primitive type other than string would potentially run into this same scenario, though for the other ones like fixedDelayMilliseconds defaults to 0 so it ends up being the behavior that would be expected anyway. In this particular usage, it looks like the only fields that are not objects or strings are priority, persistent, fixedDelayMilliseconds, and fromConfiguredStub. I think only the last one is likely to need the change.

[StefH]

For now I will just fix the FromConfiguredStub.

[StefH]

#1142