Allow the creation of requestBody

[savage-alex]

When variation testing, I would like to test my GET endpoints correctly reject requests that contain a requestBody.

I have a overwriteRequestBody overwrite enabled but it is not possible to create new objects / add objects to a body, only overwrite existing properties:

{
                "openApiOperation": "GET::/*",
                "openApiResponse": "400",
                "variations": [
                    {
                        "name": "getWithBody",
                        "overwrites": [
                            {
                                "overwriteRequestBody": [
                                    {
                                        "key": "firstName",
                                        "value": "foo",
                                        "overwrite": true
                                    }
                                ]
                            }
                        ],
                        "tests": {
                            "contractTests": [
                                {
                                    "statusCode": {
                                        "enabled": true
                                    },
                                    "schemaValidation": {
                                        "enabled": true,
                                        "additionalProperties": false
                                    },
                                    "contentType": {
                                        "enabled": true
                                    }
                                }
                            ]
                        }
                    }

Is this something that would be useful to add?

(Note we can and do insert new query params in the same way to ensure unknown query params are rejected

[thim81]

@savage-alex
If things work as expected, you can overwrite the request body, where by using "." as key this targets the root element.
As as value you can set an single value (like a string, number, ...) or a full object ({}) or an array ([])

{
   "key": ".",
   "value": { "foo": "foo-bar-baz" }
}

In the Portman, you can see some examples in the tests

[thim81]

I delivered a bad example, the object should be an "object" (without the "") instead of string.

[savage-alex]

This overwriteRequestBody will add the following key at root level

 {
                                "overwriteRequestBody": [
                                    {
                                        "key": "foo",
                                        "value": "foo-bar-baz' ",
                                        "overwrite": true
                                    }
                                ]
                            }

Perfect test to see how a PUT operation will behave with an unknown property.

Sadly the issue with GET remains where it is not created at all.

[AliKhalili]

@savage-alex I think adding request body for those operations which do not have request body is a legitimate variation test.
Portman ignores this scenario, @thim81, Could you please tell us is there any specific reason behind that?
It would be my pleasure to add this new feature with a PR.

[thim81]

The idea behind Portman is to build tests based on the defined properties in OpenAPI for the Happy path and fiddle with the properties that are defined for the variations. This to reduce the repetitive work of defining the same request/responses everywhere (docs, tests, ...). OpenAPI is our single source for everything, hence the term "spec-driven development".

So if it doesn't exist in OpenAPI, Portman will have trouble to deduce test from it and build a Postman request. Example: If there is no response body, then Portman cannot generate tests to verify the expected, documented response. If there is no request body defined, it is difficult to create one, since it would miss plenty of request context.

[savage-alex]

Hi @thim81, thanks for the considered response on this. It makes total sense.
We saw this case as an opportunity to automate the repetitive task for our testers to ensure compliance with the spec:

• If the spec says there can be no body, did the API correctly reject one that was sent.
• We do this currently with a special postman operation that we hijack bodies into via a script.
• The variation or fuzzing of injecting things like headers and query prams works great (I have built a case for an unknown query param variation which works brilliantly). This was the next case we planned to try and automate as its something we have fallen fowl of before (its one from my playbook thats made other peoples APIs fall over.)

Perhaps we misunderstood the true purpose of portman and are trying to mod it to the point it is a contact tester for all our positive and negative scenarios (we have header tests, query tests, body tests that I am trying to automate). For me contract compliance is about doing what you promised in the OpenAPI which exists for both doing what I said I would and only that. If its not in the definition, I am going to reject it (I just want to make sure we are doing that correctly)

Thanks