Establish proper test suite for `sourcemeta::jsontoolkit::URI`

sourcemeta / jsontoolkit

A swiss-army knife for expressive JSON programming in modern C++. Covers JSON, JSON Pointer, JSONL, and JSON Schema

https://jsontoolkit.sourcemeta.com/

Other

39 stars 3 forks source link

Establish proper test suite for `sourcemeta::jsontoolkit::URI` #953

Open tony-go opened 3 months ago

tony-go commented 3 months ago

As much we move forward on #710, we figured out that writing a good tests suit is essential.

We want to have a test suit for RFC3986 URI https://www.rfc-editor.org/rfc/rfc3986! The goal of this issue is to gather every piece of information we could find on the topic.

tony-go commented 3 months ago

Findings:

RFC 2396

http://lists.w3.org/Archives/Public/www-qa/2001Aug/0000.html https://lists.w3.org/Archives/Public/www-qa/2001Aug/0000.html https://www.w3.org/2004/04/uri-rel-test.html

RFC 3986

https://cr.openjdk.org/~dfuchs/writeups/updating-uri/

tony-go commented 2 months ago

What is your view on the finaly goal @jviotti ?

Having a standalone test suite? or
Enrich our test suite with more cases?

tony-go commented 2 months ago

I would like to share my vision about my previous comment.

I'd rather go for the second option, for two reasons:

We would like to benefit from our research as soon as can, by strengthen our test suite This is by doing a lot research that at some point we could have a fully compliant tests. (That could give, on the end, a standalone suite)
Even if having a fully compliant RFC3986 URI parser is the final goal, we should not forget that we first serve jsontoolkit. What I mean is that if we wait to have a full standalone suite before replacing uriparser, it could take a lot of time as once we finally have it we would like to make it review by fellow engineers...

In a one word my vision is to do a first research, extract all what we can from these, open PR (like this one) and then continue to do research on side while we move forward on critical topics for the project.

jviotti commented 2 months ago

@tony-go Sorry if I wasn't clear at the beginning. I indeed meant enriching our test suite with more tests, borrowing test suites from other places. The idea being that if we want to get rid of uriparser, let's have a more comprehensive set of tests (vs the basic ones I had right now) so we make sure we avoid pitfalls on complex areas like parsing or resolution.

jviotti commented 2 months ago

Some other test suites I know:

Hyperjump's URI parser: https://github.com/hyperjump-io/uri/blob/main/lib/parse.spec.ts, https://github.com/hyperjump-io/uri/blob/main/lib/resolve-reference.spec.ts, and https://github.com/hyperjump-io/uri/blob/main/lib/validation.spec.ts
uriparser itself has some interesting ones: https://github.com/uriparser/uriparser/blob/master/test/test.cpp, and https://github.com/uriparser/uriparser/blob/master/test/FourSuite.cpp
Browsers have interesting ones for URLs, like WebKit: https://github.com/WebKit/WebKit/tree/main/LayoutTests/fast/url

jviotti commented 2 months ago

I think we can re-adapt many of those rather quickly with some ChatGPT/Claude help :D Then we'll be super confident when doing larger changes on the module, and eventually extracting it into URI Kit.