Looping is in some ways inevitable but this aims to make it less brittle by:
Introducing a common test suite definer function (defineSuiteConformanceTests) to encapsulate the looping
Decouples looping from test definitions by introducing an intermediate data structure
This greatly simplifies the RDFC verify and SD verify tests (there's still some janky data structures in the latter test (e.g., defineTestVectorMapping) but at least it is more obvious now.
I wrote it so we can use it for all the suites tests though the PoC only implements it for verifier tests for simplicity.
On the plus I think we can use this definer function with all the other test suites, since they all seem to do this crap (and it is baked into the current reporter)
From original PR
Remove name from achievement doc use VC 2.0 name term.
Add valid vc2.0 and vc1.1 test fixtures.
Add VC1.1 and VC2.0 of achievement mock.
Add 1.1 and 2.0 sections to configs/vectors.json.
Use vcTypes in rdfc create test.
Check supports.vc & supports.keyTypes.
Lint rdfc create test suite.
Switch rdfc verifiers to VC 1.1 and VC 2.0 test data.
Do not run rdfc verifier tests if verifier does not support vc version.
Move sd create into VC block, correct createInitialVc, await verificationSucess.
Lint sd create file.
Use vectors in sd-verify.
DRY Up endpoint checks into new helper function.
Pick first verifier from filter.
Change issueTestData to issueCredentials.
Produce rdfc verification data before suite starts.
Abstract sd setup to a separate file.
Add vcVersion to sd verify & use deriveCredentials.
Change verifiableCredential to credentials in deriveCredentials.
Rewrite deriveCredentials to work with the Map vectors.
Take over and continuation of https://github.com/w3c/vc-di-ecdsa-test-suite/pull/69.
Refactor notes
I think I found an approach that simplifies the test suites a bit by avoiding the delicate nested for loops: https://github.com/w3c/vc-di-ecdsa-test-suite/pull/73/files#diff-d30b2f3c1314b63df05e03756fe73a369890598d83a5383fbcd9528b74963acf
Looping is in some ways inevitable but this aims to make it less brittle by: Introducing a common test suite definer function (
defineSuiteConformanceTests) to encapsulate the looping Decouples looping from test definitions by introducing an intermediate data structureThis greatly simplifies the RDFC verify and SD verify tests (there's still some janky data structures in the latter test (e.g., defineTestVectorMapping) but at least it is more obvious now.
I wrote it so we can use it for all the suites tests though the PoC only implements it for verifier tests for simplicity.
On the plus I think we can use this definer function with all the other test suites, since they all seem to do this crap (and it is baked into the current reporter)
From original PR
Remove name from achievement doc use VC 2.0 name term.
Add valid vc2.0 and vc1.1 test fixtures.
Add VC1.1 and VC2.0 of achievement mock.
Add 1.1 and 2.0 sections to configs/vectors.json.
Use vcTypes in rdfc create test.
Check supports.vc & supports.keyTypes.
Lint rdfc create test suite.
Switch rdfc verifiers to VC 1.1 and VC 2.0 test data.
Do not run rdfc verifier tests if verifier does not support vc version.
Move sd create into VC block, correct createInitialVc, await verificationSucess.
Lint sd create file.
Use vectors in sd-verify.
DRY Up endpoint checks into new helper function.
Pick first verifier from filter.
Change issueTestData to issueCredentials.
Produce rdfc verification data before suite starts.
Abstract sd setup to a separate file.
Add vcVersion to sd verify & use deriveCredentials.
Change verifiableCredential to credentials in deriveCredentials.
Rewrite deriveCredentials to work with the Map vectors.
Use keyTypes from config in sd verify.
Interop uses vc 1.1 for now.