Test suite should be split into its own repo

[gregsdennis]

Having a reference implementation and a test suite are to themselves good things. I don't know that they necessarily belong together, though.

The test suite should be something that an implementor can use to verify their implementation. They don't need the reference implementation to do that.

The JSON Schema Test Suite is a good pattern to follow. It only outlines the tests in a deserializable format that gives some test data and the expected result.

This file from the JSON Path Comparison site code is probably the best place to start for getting test cases. I've implemented this as an interim suite, using those cases that have consensus as the desired outcome (save for a few exceptions). Though I think serializing it with JSON might make things easier (since we're defining a JSON mechanism and we should already have tooling to deal with it versus YAML).

[f3ath]

I'm developing the Dart implementation and the existing cts.json seems very convenient. Until it is separated into its own repo, I'm asking for permission to copy it over to my project as is. @glyn please let me know if you're OK with it.

[glyn]

@f3ath That's fine. To be squeaky clean, you should probably note somewhere in the project that cts.json is covered by a BSD 2 license. Also, it may be worth putting cts.json in its own directory if you would eventually embed the CTS as a git submodule (see below).

However, I'm wondering if now is the time to split out cts.json (together with supporting docs, LICENSE, etc.) into its own repo which implementers could then embed as a git submodule. If it was in a separate repo, would you choose to embed it as a submodule or would you prefer to take a copy and synchronise that manually from time to time?

[gregsdennis]

For information, I submodule this repo (will update if it's split out). See https://github.com/gregsdennis/json-everything, ref-repos folder.

[f3ath]

Thanks @glyn I will let you know once I push the changes.
To answer your question, I was thinking about a submodule. Precisely, I would wrap it into a Dart package itself so that the dependency tree would be like json_path ==(requires as a Dart package)=> json_path_test_suite ==(requires a git submodule)=> cts.json

[glyn]

@f3ath Please note the new repo: https://github.com/jsonpath-standard/jsonpath-compliance-test-suite