You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could we find a "definitive" structure for organizing tests and specs?
What about we use spec id or PR to the spec repo as a test name and spec id work?
Take cors, we could have cors-000 (before specification, tests coming from sharness), then cors-pr-423, etc.
The current "mainstream" version of cors would be a spec group with all the specs that compose a regular cors gateway.
We could even pin these on dates, like cors-2023 would be all the specs active during 2023.
End goal is:
structure is deterministic so that contributors & users know how to go from spec to tests,
this opens up a way to connect the process of adding test with adding IPIP specs.
The text was updated successfully, but these errors were encountered:
We had a few back and forths with test structures, spec names, etc.
See https://github.com/ipfs/gateway-conformance/pull/79/files, #92 (comment), and #87 (comment).
Could we find a "definitive" structure for organizing tests and specs?
What about we use spec id or PR to the spec repo as a test name and spec id work?
Take cors, we could have
cors-000
(before specification, tests coming from sharness), thencors-pr-423
, etc.The current "mainstream" version of cors would be a spec group with all the specs that compose a regular cors gateway.
We could even pin these on dates, like
cors-2023
would be all the specs active during 2023.End goal is:
The text was updated successfully, but these errors were encountered: