Open ahmednfwela opened 1 year ago
kuhnroyal
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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.
The Problem
Looking at
bin/configs/dart*There are currently 5 dart-dio configsand 2 dart configs
And with the addition of freezed serialization option in https://github.com/OpenAPITools/openapi-generator/pull/13047 And http networking option in https://github.com/OpenAPITools/openapi-generator/pull/14346 And with future support for OAS 3.1 https://github.com/orgs/OpenAPITools/projects/4
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 https://github.com/OpenAPITools/openapi-generator/pull/14346 will have to be merged to unify both
dartanddart-diogenerators into onedartgenerator.I propose creating one gigantic schema that tests everything in the spec, one for
version: 3.0and one forversion: 3.1which uses a variant of the new Echo Server APIMaybe 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:
Note:
manualrefers to the current serialization/deserialization method in thedartgeneratormultiplied by version:
so with only 2
echo_api.yamlschemas (one for3.0.0, and one for3.1.0), we can get 16 different configs, meaning we get 16 different dart projectsThe Tests
Currently for
dart-diowe generate atestsfolder 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-serverimplementation 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)