File a new PR for first iteration (TP req.: RHOAR QE migration + customer scenario App)

[fabiobrz]

• [x] Code refactoring/cleaning and uniforming with current MP OpenAPI tets codebase style
• [x] Java doc
• [x] Extract test opportunities to satisfy TP requirements: RHOAR QE migration + customer scenario APP
• [x] Design application first stub
• [x] Review test classes/methods
• [x] Map test criteria with TPG tags
• [x] Send PR

[fabiobrz]

Extract test opportunities to satisfy TP requirements: RHOAR QE migration + customer scenario APP

Two type of tests have been migrated with a 1-1 mapping from RHOAR QE TS to EAP MP TS, see [1]:

• Thorntail samples Covers difference between v10 and v11 annotations => can be used to demonstrate compatibility issue for customer running v10 statics files?
• Java EE MicroProfile examples
  Covers Programming Model scenario => can be used to demonstrate fixing the output (e.g.: complex custom response types like PageResource<MyType> etc.)

[1] https://github.com/jboss-eap-qe/eap-microprofile-test-suite/issues/11

[fabiobrz]

Design/develop application first stub

• First stub for an application which would satisfy above requirements could be implemented quickly by merging all the "Application" classes used by original migrated tests into a single one.
• Then a real-life scenario must be created for this application. This will allow for designing workflows to implement test cases and also to shape application better, not to mention giving a name to it

[fabiobrz]

Extract test opportunities to satisfy TP requirements: RHOAR QE migration + customer scenario APP

• Thorntail samples App could expose a first self-explanatory endpoint in order to verify v10 annotations and another one that needs for some v11 improvement

• Jave EE MicroProfile examples: App could expose a first endpoint that has a complex POJO and has ha filter that fixes OpenAPI output (could include also automation based on output -> generation?)

[fabiobrz]

Design/develop application first stub

• Thinking about using/modifying https://dzone.com/articles/handling-with-pagination-with-jax-rs-in-your-jakar

• Experiments to use a complex return value for GET

[fabiobrz]

Design/develop application first stub

• Experiments to use a complex return value for GET => trying to see generics in OpenAPI (e.g. nested objects too)

• if no joy => change scenario to fix some weird char with filter

[fabiobrz]

PR was sent, see https://github.com/jboss-eap-qe/eap-microprofile-test-suite/pull/79

Testing scenario

The scenario involves a Services Provider deployment which services - which are mainly get* operations, i.e. just for consultation - are meant to be accessed only by Local Service Routers. This scenario comes from previous personal working experience cases and provides with several testing opportunities which could be mapped to TP requirements. First iteration is supposed to add coverage for tests migrated from [1] for which following test case scenario has been implemented (Note: no Local Service Router app has been developed yet because not needed for this initial work).

Services Provider (SP) is exposing services that can be accessed only by authorized and well known Local Service Routers (LSR), which in turn are available to the public. For this reason LSR are requested to expose the same services that the SP expose and to route the call to it in order to get results which will be finally sent to the end-user.

MP OpenAPI fits perfectly this scenario - see the specs [2] - thus the JAX-RS resource (DistrictResource) provided by SP application has JAX-RS or proper MP OpenAPI annotations to let the /openapi endpoint return correspondent OpenAPI compliant document for LSRs to implement both their own facade to public audience and to internally call the SP services, too.

Testing opportunities to cover TP requirements for [1]:

• Tests were designed to match the following real-life use cases:

1. Services Provider developers must provide PoC to guarantee that Local Service Routers vendors can easily manipulate generated doc contents to modify some properties, e.g. the operation extension used to document which local router is actually exposing the service to the public.
2. Services Provider developers must provide PoC to guarantee that operations having just JAX-RS annotations are properly documented for params.
3. Services Provider developers must provide PoC to guarantee that operations having just JAX-RS and @ApiResponse (to specify @Schema) annotations are properly documented.
4. Services Provider developers must provide PoC to guarantee that new annotations/features available in v11 are properly documented.

• In order to fulfill the above tests opportunities, 3 classes have been implemented to store all the migrated test cases:

1. ProgrammingModelTest provides coverage for Java EE Microprofile samples - which operate through the programming model for MP OpenAPI - and verifying programmatic modification to the generated document [see case 1.].
2. OpenApi10OnJaxRsAnnotationsTest provides coverage for RHOAR QE TS v10 tests, verifying that the generated YAML contains both information generated from JAX-RS annotations and from @ApiResponse/@Content/@Schema` definition [see case 2. and 3.].
3. MicroProfileOpenApi11Test provides coverage for RHOAR QE TS v11 tests, verifying new features as: patch being documented, example attribute for @Content and parseValue for @Extension[see case 4.].

[1] jboss-eap-qe#11

[2] https://download.eclipse.org/microprofile/microprofile-open-api-1.1/microprofile-openapi-spec.html#_introduction