Start unit testing... seriously...

[ffMathy]

This library is so full of bugs and regressions that it's absurd.

I hear there's a new TypeScript rewrite going on? Just wanted to make sure that unit tests are being a part of that.

Every time I contribute to fixing a bug here, it gets ruined again 4 - 6 months after. In addition, everytime something is "fixed", it ends up getting re-opened again because the fix broke someone else's flow.

Start 👏 Creating 👏 Unit 👏 Tests 👏

It's a must for such a big library. Then, whenever someone "fixes" something, require that they make a test for that specific scenario. In time, we'll then have a lot of concrete cases to work with.

The tests should be easy to implement.

In addition, I think there should be two types of tests. Compile-tests, and runtime tests.

An example of a compile-test:

1. Specify a swagger.json file as an argument to some function.
2. Generate client code.
3. Check that the client code compiles.

An example of a runtime-test:

1. Specify a swagger.json file as an argument to some function.
2. Generate client code.
3. Call the client code with some sample API response, to see if it behaves correctly.

I have lost faith in this library. This is my last cry for help. You must see the relevance in this.

[ffMathy]

I realize that there may already be some tests, but the above approach should work more effectively. The right areas are not being tested, leading to tons of issues.

[spacether]

Hey there;
Sorry to hear that you have been running into a lot of issues and regressions with our project.
We definitely don't want that to happen.
I ask that contributors create a test for features they add or bugs they fix.
A thorough unit test spec would be a great addition to our project. It could have things like:

• schemas of all types and formats in all places
• referenced schemas of all types and formats in all places
• nullable schemas in all places
• include components for all validation keywords

json schema has some test specs that could be used as a starting point. Does anyone want to write a PR improving our project in the way that this issue suggests?

[spacether]

Some background info here:

openapi-version	json-schema-version	json schema tests
3.1.0	2020-12/draft-bhutton-json-schema-00	draft2020-12
3.0.3	Draft5/draft-wright-json-schema-00	None: Draft 5 wasn't an official release for JSON Schema. It was more of a trial. Publishing it was skipped as we took lessons learned into draft 6. per a comment in in json-schema Slack. If one wanted to one could use Draft6 tests with omissions

Json schema spec versions: https://json-schema.org/specification-links.html

Per json schema draft6:
examples: This keyword can be used to provide sample JSON values associated with a particular schema, for the purpose of illustrating usage. It is RECOMMENDED that these values be valid against the associated schema.

Openapi v3.1.0 describes examples:
In all cases, the example value is expected to be compatible with the type schema of its associated value. Tooling implementations MAY choose to validate compatibility automatically, and reject the example value(s) if incompatible.

Openapi v3.0.3 describes examples:
Examples of the parameter's potential value. Each example SHOULD contain a value in the correct format as specified in the parameter encoding.

[spacether]

Also for the record, people have added many unit tests using sample specs that they put in this directory:
https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/test/resources/3_0