[REQ] [dart-dio] [internal refactor] Unify test schemas

[ahmednfwela]

The Problem

Looking at bin/configs/dart*
There are currently 5 dart-dio configs

• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-dio-oneof-polymorphism-and-inheritance.yaml
• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-dio-oneof-primitive.yaml
• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-dio-oneof.yaml
• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-dio-petstore-client-lib-fake-json_serializable.yaml
• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-dio-petstore-client-lib-fake.yaml

and 2 dart configs

• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-petstore-client-lib-fake.yaml
• https://github.com/OpenAPITools/openapi-generator/blob/master/bin/configs/dart-petstore-client-lib.yaml

And with the addition of freezed serialization option in #13047
And http networking option in #14346
And with future support for OAS 3.1 Add support for OpenaApi v3.1.0 specs to openapi-generator

We are going to need way more configs and more test schemas to test all possible permutations

Currently all the schemas we use are stored in modules/openapi-generator/src/test/resources/3_0

and a lot of these schemas are used for tests for the core generator itself

Proposed Solution

as a prerequisite, this PR #14346 will have to be merged to unify both dart and dart-dio generators into one dart generator.

I propose creating one gigantic schema that tests everything in the spec, one for version: 3.0 and one for version: 3.1
which uses a variant of the new Echo Server API

Maybe we can also utilize this PR to merge small spec files instead of one big file

This new schema will then get generated against all possible permutation of options
so we will have the following new configs:

	http	dio
json_serializable	dart-http-json_serializable	dart-dio-json_serializable
built_value	dart-http-built_value	dart-dio-built_value
freezed	dart-http-freezed	dart-dio-freezed
manual	dart-http-manual	dart-dio-manual

Note: manual refers to the current serialization/deserialization method in the dart generator

multiplied by version:

	V3	V3.1
dart-http-json_serializable	v3/dart-http-json_serializable	v3.1/dart-http-json_serializable
dart-http-built_value	v3/dart-http-built_value	v3.1/dart-http-built_value
dart-http-freezed	v3/dart-http-freezed	v3.1/dart-http-freezed
dart-http-manual	v3/dart-http-manual	v3.1/dart-http-manual
dart-dio-json_serializable	v3/dart-dio-json_serializable	v3.1/dart-dio-json_serializable
dart-dio-built_value	v3/dart-dio-built_value	v3.1/dart-dio-built_value
dart-dio-freezed	v3/dart-dio-freezed	v3.1/dart-dio-freezed
dart-dio-manual	v3/dart-dio-manual	v3.1/dart-dio-manual

so with only 2 echo_api.yaml schemas (one for 3.0.0, and one for 3.1.0), we can get 16 different configs, meaning we get 16 different dart projects

The Tests

Currently for dart-dio we generate a tests folder that contain model tests, these aren't really useful at the moment (I think they were supposed to test model usage/serialization/deserialization)

Instead what I propose, is to replace those tests with a simple echo-server implementation in dart (using shelf for example)
and make sure each permutation of the generated files has the proper tests working, that test it against the provided examples

---

@wing328 @jaumard (2018/09) @josh-burton (2019/12) @amondnet (2019/12) @sbu-WBT (2020/12) @kuhnroyal (2020/12) @agilob (2020/12) @ahmednfwela (2021/08)

[kuhnroyal]

The generated tests are not useful, they are just a template for the users. Generating tests that make requests would require dynamic test data that is still reproducible on every generation.
Thats why there is a separate test sample project with some tests for dart-dio+built_value.

In general I like the idea but I see the problem of this generator getting so big that it will get hard & slow to iterate.

[ahmednfwela]

Generating tests that make requests would require dynamic test data that is still reproducible on every generation

this is why I said we use both echo server AND the example objects per model/endpoint.
with these 2 information, we can generate a request (from the example) send it, receive it again (from echo server) and check if they both match (using deep map equality)

In general I like the idea but I see the problem of this generator getting so big that it will get hard & slow to iterate.

we can solve this by a simple refactor of the generators to allow pluggable serialization mechanisms

[wing328]

this is why I said we use both echo server AND the example objects per model/endpoint.

I like this. That's the direction other generators are heading too.