Different SWAGGER_JSON_URL for different tests?

[Kumar Gaurav]

In test examples, there is one swagger JSON url being used in all tests in a test class. Is it possible to use different JSON urls for different tests? We group specifications as per api version in swagger and so the json url for each group is different in the format: http://localhost:8080/v2/api-docs?group=<version_number>

Version number in our case is the value of a custom header: X-MY-HEADER. I was wondering whether I could use the mock request information to check which json url to validate against. Do you think its possible?

A workaround in my case is to have different test classes for different api versions.

Thanks a lot.

[James Navin]

At the moment the validator makes some pretty in-grained assumptions about there being only a single spec to validate against.

Could you just create multiple instances of the validator (or validation filter - Im not sure which specific module you're using) and choose which one to use in your tests based on the API you're exercising?

[Kumar Gaurav]

Thanks. Will try that.

[Kumar Gaurav]

I am still confused about the best way to integrate provider tests in CI. It needs JSON url so provider application under test needs to be running. Do you deploy provider app in an environment (e.g. in QA env.) as part of CI step and run provider test? OR Do you run application while running test (Application.run() in @BeforeClass step) and do the validation.

Also as its validating against specification, I suppose it does not need application to have data related to request, right?

[James Navin]

@gaurav517 apologies for the delay getting back to you - I haven't had much time to focus on this project lately.

It depends what you mean by "provider tests".

If you are specifically meaning "provider" in the context of Pact - the PactProviderValidator can be used to statically validate that the Pacts created by consumers match the API spec for the Provider. If you can access the Provider swagger spec without starting the Provider application then there is no need to start it for these tests (e.g. no requests will be executed against the Provider application).

If you mean "provider" in a more general sense - then whether or not you need to start the application depends on what exactly you're testing.

For example, if you were using the e.g. RESTAssured module to validate that your implementation matches its API specification, then you would need to start the application first before you could make requests against it (or have it running in some environment somewhere). How you start your application depends a lot on what stack you're using etc.

Does that help at all?

[Kumar Gaurav]

Thanks @jnavin for clarification. I meant 'provider' in the context of pact and I got an idea before looking at code. What I concluded is that if we want to use PactProviderValidator then we need to generate API spec before running the test. I am currently thinking of trying: Swagger Maven Plugin (https://github.com/kongchen/swagger-maven-plugin). Please let me know if you have any better idea. Thanks.

[James Navin]

Something like that plugin would work fine.

In my team our services are all Spring Boot based, so its pretty trivial to start them during tests. In those cases we use the 'live' hosted Swagger spec to drive our validated REST Assured tests.

Are you happy for me to mark this issue as resolved? (Im happy to continue the conversation in comments if you like)

[Kumar Gaurav]

Resolving as per discussion.