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
Up for discussion: Currently, there are no test cases for the spec, making it hard to determine whether an implementation is adhering to the spec or not. Currently, Jelly-JVM uses a set of test cases in scalatest, but these are not easy to reuse in any way.
I think we should have a test kit for the spec that would check the support for each individual capability, and then also the behavior of the implementation on more complex, real-world use cases. This is of course tightly linked to the Jelly protocol profiles (#24), which would decide which test cases are appropriate.
We can most likely reuse a lot of the test cases from Jelly-JVM. It should then of course be migrated to the new test case system.
Licensing may be important here. To avoid headaches with reusing the test cases in codebases, I'd strongly suggest to make the test cases CC-zero. I really do not want any license compatibility issues here, and I don't see any good reason why the test should not be CC-zero.
The text was updated successfully, but these errors were encountered:
Somewhat related to #24
Up for discussion: Currently, there are no test cases for the spec, making it hard to determine whether an implementation is adhering to the spec or not. Currently, Jelly-JVM uses a set of test cases in scalatest, but these are not easy to reuse in any way.
I think we should have a test kit for the spec that would check the support for each individual capability, and then also the behavior of the implementation on more complex, real-world use cases. This is of course tightly linked to the Jelly protocol profiles (#24), which would decide which test cases are appropriate.
To keep things as standardized as possible, I'd suggest to reuse/extend the W3C's work on RDF Test Cases: https://www.w3.org/TR/rdf11-testcases/
We can most likely reuse a lot of the test cases from Jelly-JVM. It should then of course be migrated to the new test case system.
Licensing may be important here. To avoid headaches with reusing the test cases in codebases, I'd strongly suggest to make the test cases CC-zero. I really do not want any license compatibility issues here, and I don't see any good reason why the test should not be CC-zero.
The text was updated successfully, but these errors were encountered: