Skip to content
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

Open
wants to merge 58 commits into
base: develop
Choose a base branch
from

Conversation

thim81
Copy link
Contributor

@thim81 thim81 commented Jun 1, 2020

This feature proposal contains 2 implementations, with the aim to facilitate & automate contract testing using Postman, based on OpenApi specifications:

  1. Provide the option to generate real basic response postman tests, generated/added based on the OpenApi spec file. (Success status check / Response time check / Content-type check / JSON schema validation (based on the OpenAPi components) / JSON body check)
  2. Provide additional manually created Postman test scripts. The manual postman tests will be added per OpenApi operationId. This will give enough granularity to define specific tests.
  3. Provide a option to overwrite/extend the Postman Request body, Query params, Path Variables & Headers as part of the Testsuite generation.
  4. Provide the option to define pm.environment variables for automation, by assigning values from the response. Automatically a pm.environment variable for the POST response will be provided

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:

  • Success status check
  • Response time check
  • Content-type check
  • JSON schema validation
  • JSON body check

Why I did choose not to add tests in OpenApi spec?

  • Currently there was no property/tag available for test (Or I havent found it in the OpenApi spec). Vendor extensions could be an option but in which format/framework would you write the tests?
  • OpenApi is about documenting the API while tests have a more functional aspect. Mixing these 2 concepts in 1 would risk of complicating the OpenApi?
  • It would not be easy to find a "generic" test description. In which format/framework would you write OpenApi tests? The Postman test format is a distinct direction and personal preference, so this would not belong in the OpenApi.

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:

  1. OpenApi with examples and schemas
  2. Filter out unwanted OpenAPI methods/Operations via openapi-filter
  3. openapi-to-postman generates a postman collection with tests.
  4. the postman collection ran with just setting an postman env. The examples from OpenAPI are used in the postman collection. The OpenAPI schema is used in the postman tests.
  5. via newman we run the tests and validate the api contracts.
  6. via the Newman report we can view what failed

This all automated in an Azure Pipeline.

Additions:

  • Merged Feature/cli converter options #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 Feature/cli converter options #218) option for the CLI
  • Added postman-testsuite.json example

- 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.
@thim81 thim81 changed the title Added test generation for: New Feature - Generate tests from OpenAPI / Swagger yaml or json file #56 Jun 1, 2020
Tim added 10 commits June 1, 2020 12:41
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.
@thim81 thim81 changed the title New Feature - Generate tests from OpenAPI / Swagger yaml or json file #56 New Feature - Generate tests from OpenAPI / Swagger - automated contract testing #56 Jun 14, 2020
@thim81
Copy link
Contributor Author

thim81 commented Jun 15, 2020

@VShingala Is it advised to keep PR's up-to-date with the changes on the "develop" branch?

@VShingala
Copy link
Member

@thim81 yeah, it would be good to keep it up to date with develop branch.

@thim81
Copy link
Contributor Author

thim81 commented Jun 24, 2020

Testsuite configuration
image

Postman testsuite results
image

@thim81
Copy link
Contributor Author

thim81 commented Jul 1, 2020

@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?

@kharoutaj
Copy link

kharoutaj commented Jul 11, 2020

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?

@thim81
Copy link
Contributor Author

thim81 commented Jul 13, 2020

@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.
You can check the reasons in the original issue: #56 (comment)

@SidhNor
Copy link

SidhNor commented Nov 16, 2020

Hey guys, any plans to rebase / merge this?

@thim81
Copy link
Contributor Author

thim81 commented Nov 16, 2020

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.

@CleverCoder
Copy link

Extending on my comments here: #56

  • The header "overwrite" isn't working for me. Seems to be due to how the "faker" stuff is designed
  • Wouldn't this be better implemented as a "value provider", and the current "faker" can be turned into a value provider? This way the code has a single implementation for providing a value for auth/header/body, etc.. and the provider can be the default, or this more flexible implementation
  • What about authorization? It seems to not address the need to change the value being provided in the auth header. the generated collection just shows . This is pretty important for automation.
  • Matching on operationId is too limiting. I'd suggest using RegEx against a path such as "VERB:PATH", ie: "post:/some/test/endpoint"... or ".*:/widgets".. maybe a simpler glob match..

Keep it up!!

…JSON schema properties which deletes nullable and adds "null" to type array if nullable is true
@thim81
Copy link
Contributor Author

thim81 commented Mar 11, 2021

@CleverCoder

Valid comments, I replied to them in the feature #56

Tim added 10 commits April 20, 2021 17:28
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)
@thim81
Copy link
Contributor Author

thim81 commented Jun 18, 2021

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

https://www.npmjs.com/package/@apideck/portman

@thim81
Copy link
Contributor Author

thim81 commented Jul 13, 2021

UPDATE: We just launched the 1.0 release of Portman, which now support contract, variation & integration testing!
I wrote a blog post about it on the Apideck website: https://blog.apideck.com/announcing-portman that gives more information.

@SidhNor
Copy link

SidhNor commented Jul 13, 2021

@thim81 congrats. Nice job. Will give it a try )

@ani-im
Copy link

ani-im commented Sep 10, 2021

Do we have any updates regarding this?
Will this PR be merged. If so, do we have deadlines?
Thanks in advance.

@thim81
Copy link
Contributor Author

thim81 commented Sep 10, 2021

@ani-im

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

@akshaydeo akshaydeo requested a review from VShingala April 3, 2023 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants