Proposal: Create new repo for openapi tests, similar to json schema test suite
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Beginne mit der Durchsicht der bestehenden Tests in OAI/OpenAPI-Specification/tests/v3.1 und der JSON Schema Test Suite, einschließlich der referenzierten int64-Arbeiten. Definiere vor der Implementierung die Repository-Struktur, die unterstützten OpenAPI-Versionen, das Testformat und die Konformitätserwartungen. Die Aufgabe ist erledigt, wenn die offenen Fragen des Vorschlags geklärt sind und ein abgegrenzter Plan für das neue Test-Repository vorliegt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
This issue is a proposal that a new repo be created that stores tests of openapi payloads, request, responses, and documents. These tests will help implementation verify that they have built features correctly.
There is existing prior work here that applies to json schema only in the json schema test suite: https://github.com/json-schema-org/JSON-Schema-Test-Suite
Need for this solution:
- there are few tests here: https://github.com/OAI/OpenAPI-Specification/tree/main/tests/v3.1 and they do not provide full coverage for openapi features, they do not describe what is acceptable and unacceptable for openapi-only schema formats, they may not be well known in the community, they do not have coverage tests for different versions of the openapi spec
- what is allowed for int32/int64/float/double is not explicitly defined in the spec or the format registry (for example is X.0 allowed in for int32?). Implementers need this info when building.
- I attempted to add int64 tests into the json schema test suite and was told that that repo is not the right place for that test, because the format is openapi-specific and is not listed in the json schema spec.
Benefits:
- tooling providers could have a verifiable way of proving that their implementation is conforming to the requirements
- long term this should reduce the number of what is the correct way to implement x feature questions on this repo because you can point them to the existing test
- including these tests in a separate repo will allow implmenters to include that repo as a subpackage and easily test against it. (I currently do this with the json schema test suite here)
- General json schema 2020-12 tests should not be included here because they already exist in the json schema test suite. Refer users to that suite also. This reduces the maintenance workload.
Proposal Short Term:
- create a new repo, Openapi Test Suite in the https://github.com/OAI org
- have one folder for each version of the openapi test suite
- move the existing tests into that
- perhaps organize the tests in the same directory structure as the openap spec?
- add tests in components/schemas/format.json which includes the int64 format tests in: https://github.com/json-schema-org/JSON-Schema-Test-Suite/pull/711
I would be happy to add additional test for int32/float/double/int formats
@karenetheridge mentioned that she could contribute tests from https://github.com/karenetheridge/OpenAPI-Modern/tree/master/t
Open Questions:
- How thorough should these tests be?
- My proposal is to incrementally add coverage bit by bit starting with easiest tests, which may be component schema formats.
- Are you okay using the json schema test suite format for the schema test files?
- What openapi versions will have tests?
- Do these tests mean that the tooling MUST/MAY/verb implement these features? (How does json schema handle this Julian Berman?)
- Vorherrschende Sprache
- Markdown
- Sterne
- 31.3k
- Forks
- 9.2k
- Ø Merge
- 2 T. 3 Std.
- Gemergte PRs (30 T.)
- 8
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus OAI/OpenAPI-Specification
-
Housekeeping
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 8/100
OAI/OpenAPI-Specification#5571 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 15/100
OAI/OpenAPI-Specification#5570 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Housekeeping
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 45/100
OAI/OpenAPI-Specification#5566 · 5 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Housekeeping
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 35/100
OAI/OpenAPI-Specification#5562 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
v3.2.1 releaseEvtl. wieder frei @lornajane hat das vor 38 Tagen übernommen, und es ist kein Pull Request offen. Offen
OAI/OpenAPI-Specification#5460 · 11 Kommentare · 1 Reaktion · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in OAI/OpenAPI-Specification
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
yologdev/yoyo-evolve#1053 ·
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
doronz88/pymobiledevice3#2051 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Groc schedules with out of range values pass config validation and fail later when the scheduler is builtEvtl. vergeben @auraseb hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
autowarefoundation/autoware_carla_scenario#342 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag