You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to create variation tests for an OpenAPI where we define default responses for all error (not 2xx) codes.
Are default responses ssupported in any way? I guess statusCodecontractTests would become quite problematic, but the other tests should be valid.
If a variation with "openApiResponse": "default" is set, examples end up in the postman collection, but no tests are created for it.
Any strategy/workaround without enumerating all the possible error codes in the openAPI spec and in the portman-config?
Example of a openapi spec:
openapi: 3.1.0info:
title: test APIdescription: | The following document contains the documentation of test APIversion: 1.0.0servers:
- url: https://localhostdescription: local test environmentpaths:
/persons:
get:
tags:
- personssummary: Get all persons.description: | Return all the data of the persons registered by the partner to the Platform.operationId: getPersonsresponses:
'200':
description: Persons retrieved.content:
application/json:
schema:
$ref: '#/components/schemas/PersonGetAllResponse'default:
description: Error occurred.content:
application/json:
schema:
$ref: '#/components/schemas/PersonErrorResponse'components:
schemas:
PersonGetAllResponse:
title: Personstype: objectproperties:
persons:
$ref: '#/components/schemas/PersonCreationResponseArray'PersonCreationResponseArray:
title: Person Response Arraytype: arrayitems:
$ref: '#/components/schemas/PersonCreationResponse'PersonCreationResponse:
title: PersonallOf:
- type: objectrequired:
- personIdproperties:
personId:
type: stringformat: uuiddescription: Unique identifier of a person.example: '123e4567-e89b-12d3-a456-426614174000'
- $ref: '#/components/schemas/PersonCreationRequest'PersonCreationRequest:
title: New persontype: objectrequired:
- personId
- firstName
- lastNameproperties:
personId:
type: stringdescription: Unique identifier of a person.example: '123e4567-e89b-12d3-a456-426614174000'firstName:
type: stringdescription: First name.example: 'John'lastName:
type: stringdescription: Last name.example: 'Doe'PersonErrorResponse:
required:
- errorstype: objectproperties:
errors:
type: arrayitems:
type: objectproperties:
code:
type: stringdescription: Error code.enum:
- PERSON_NOT_FOUND
- INVALID_FIELD_FORMAT
- MISSING_HEADER
- INVALID_HEADER_CONTENT
- PERSON_ALREADY_EXISTSexample: PERSON_NOT_FOUNDmessage:
type: stringdescription: Human readable representation of the error.example: Could not find person '1234'
At first looks, it seems that "default" is not supported.
We could investigate to bring support for it, with the assumption that you would have to define the expected "statusCode" since we cannot know what is expected statusCode that the contract should be tested against.
Let me look into it some more and report back and most likely ask some more questions about your expected behavior.
The fact that you shared already an example is really helpful.
While looking into bringing support for the "default" response, I took your example but it does not seem to generate any response in the "Variation test" folder?!
You are right, indeed the provided MVE does not create variations tests.
I'll try to conjure up an example that does, because I just retried and my complete configuration does that (but it's too complex and protected to be shared).
@Giackgamba I want to be able to reproduce it, so if you have an easy way with 1 default response to reproduce it that would be sufficient. It would reduce the time needed to get the setup going and make it easier to develop a fix.
I'm trying to create variation tests for an OpenAPI where we define
default
responses for all error (not2xx
) codes.Are default responses ssupported in any way? I guess
statusCode
contractTests
would become quite problematic, but the other tests should be valid.If a variation with
"openApiResponse": "default"
is set, examples end up in the postman collection, but no tests are created for it.Any strategy/workaround without enumerating all the possible error codes in the openAPI spec and in the
portman-config
?Example of a openapi spec:
Partial portman-config:
Partial resulting postman collection
The text was updated successfully, but these errors were encountered: