-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Feature - Generate tests from OpenAPI / Swagger - automated contract testing #56 #225
base: develop
Are you sure you want to change the base?
Conversation
- Success status check - Response time check - Content-type check - JSON schema validation - JSON body check Merged postmanlabs#218 for easy config file usage in the CLI tool. Added Postman test suite settings, which allow you to define which types of basic tests to be included or not, in the postman generation. Added Post test suite file loading (inspired by postmanlabs#218) option for the CLI Added postman-testsuite.json example Added test suite extension option, which offers the option to include manually defined postman tests based. The test extensions are mapped based on the OpenApi operationID.
Added validation for schema.$ref
It is now possible to `overwrite` all generateTests and extend them with specific settings per OpenApiOperationId.
This helps when running newman tests with reporting via CI (like Azure devops). The reporting will contain the references.
@VShingala Is it advised to keep PR's up-to-date with the changes on the "develop" branch? |
@thim81 yeah, it would be good to keep it up to date with |
@VShingala I want to add a test to the PR. Can you point me towards a good test that is using the CLI options and easy to understand? |
I took the approach of using vendor extensions for this feature for my team's project. I think it provides more granularity as you can specify tests at the individual path level in the openapi spec. I might try and clean it up if there is any interest, not sure if this implementation provides that same level of functionality. Does the operation-id field allow this? |
@kharoutaj In my PR, you can have the test suite generated based on the OpenAPI spec and still have an overwrite per path operation (each operation ID) (GET/POST/...). So I think we have similar approach. The main reason I have kept it out of the OpenApi specification is for various reasons. |
…his will only generate tests based on the defined list of operationId's.
…ere the header is checked to present in the response
Hey guys, any plans to rebase / merge this? |
Hi @SidhNor , I have been waiting for the CLI ability to configure the importer, which was officially added since v2.0.0 (October 15, 2020). Due to some other things, I've been a bit behind, so I'll merge this into my PR and rebase to have all the latest changes. Pure informational, I have been using the automated contract testing over the last 4 months and it works fine for me, so if you plan to use it or have used and have feedback, please share so I can improve my PR. |
…o replace an integer example
Extending on my comments here: #56
Keep it up!! |
…JSON schema properties which deletes nullable and adds "null" to type array if nullable is true
Valid comments, I replied to them in the feature #56 |
Patch related to the stripping of "content-type" defined in OpenAPI postmanlabs#361
…content schema. This messes up the schema validation used by the testSuite. Changed the fixed stackLimit from 10 to 999 to overcome "Error: Too many levels of nesting to fake this schema" in the schema validation Fix to prevent referenced path variables being used for overwrites
Added option to match target based on the OpenApi Operation (method & path)
Added "ContentCheck" feature
…, request body or a plain value
UPDATE: I concluded that the PR functionality does not really belong in openapi-to-postman, because this package is focussed on converting OpenAPI to Postman. Together with Nick from Apideck, we ported the PR contract testing functionality, with plenty more to the Portman package. It supports: contract testing, overwrites, assign variables + variation testing |
UPDATE: We just launched the 1.0 release of Portman, which now support contract, variation & integration testing! |
@thim81 congrats. Nice job. Will give it a try ) |
Do we have any updates regarding this? |
This PR is discontinued. Instead we ported the PR contract testing functionality, to a dedicated package >> https://www.npmjs.com/package/@apideck/portman Under the hood it is using openapi-to-postman, to convert the OpenAPI specification to a Postman collection, with all the same conversion options, with additional options to inject: contract testing, overwrites, assign variables + variation testing |
This feature proposal contains 2 implementations, with the aim to facilitate & automate contract testing using Postman, based on OpenApi specifications:
An example and the properties are explained here: the https://github.com/thim81/openapi-to-postman/blob/develop/TESTGENERATION.md
The test generation for option (1) can be can be added in the test suite configuration file where all information with regards to the preferences for the different tests for option (1) can be managed. This will also allow addition of new basic tests in next versions.
The manual test postman scripts are also managed in the test suite configuration file, grouped per OpenApi OperationId.
The use-case is to facilitate API CREATE operations with dynamic data, where we provide the option to overwrite/extend the OpenAPI request body, Query params & Path Variables with more specific values or the dynamic variables provided by Postman, desired by the Testsuite.
By having the option to overwrite the Query Param, Path variables & headers, it will be easier to automate chaining / workflows as part of the automation.
By automatically creating a pm.environment variable based on the response ID property.
This ID property can be easily used for chaining the POST create operation and the DELETE operation, through the usage of this pm.environment variable.
If the test suite configuration file is not added or if certain best tests are not "enabled".
There will be no impact, since this feature implementation is fully optional.
Currently the following Postman tests are generated automatically:
Why I did choose not to add tests in OpenApi spec?
The feature proposal provide a way to add/generate Postman tests based on the OpenApi spec.
This keeps the OpenApi "clean" and allows specific Postman implementation options.
For your information, the test functionality is being used in an CI pipeline and it works great for contract testing via Postman.
The flow is defined as following:
This all automated in an Azure Pipeline.
Additions: