- From: Markus Sabadello <markus@danubetech.com>
- Date: Mon, 29 Aug 2022 18:03:44 +0200
- To: public-credentials@w3.org
We're not yet running DID Resolution test results on a regular basis, but here's an example of what they look like: https://danubetech.github.io/did-resolution-test-suite/gh-pages/2022-05-17_00:31:21/mochareports/reports.html Markus On 29.08.22 15:08, Manu Sporny wrote: > On Mon, Aug 29, 2022 at 12:38 AM Markus Sabadello <markus@danubetech.com> wrote: >> Regarding "getting a jump-start on a DID Resolution test suite", there is already such a test suite: >> https://github.com/danubetech/did-resolution-test-suite > +1, apologies for the miscommunication on my part. What I was trying > to say was that "implementers could get a jump-start on integrating > with *a* nascent DID Resolution test suite". The ultimate DID > Resolution test suite will be the one that Markus points to above. > Implementers can get the simplest "Read" test working by integrating > with the did:key Method test suite, and then integrating with the more > complete DID Resolution test suite above when they want to be fully > compliant with the DID Resolution specification. > >> I think we should contribute this to CCG too. > +1 > > Is there a place where the test results are run on a regular basis > with a output report (we'll need that for the implementation report at > W3C, if that's where we want to send the DID Resolution > specification). > >> Sometimes the boundary between a DID method test suite (such as did:key) and a DID Resolution test suite is debatable, e.g. I raised an issue which lists a few tests that in my opinion should be moved from the did:key test suite to the DID Resolution test suite, since they test something that's not method-specific: >> https://github.com/w3c-ccg/did-key-test-suite/issues/22 > Yes, agreed that those are generalized tests, and as you said it's > debatable where they should go. The options include: > > 1. In the DID Resolution test suite. > > 2. In each DID Method test suite (as a basic sanity check since the > requirements come for DID Core). > > 3. In both places. > > We put it in the did:key Method test suite because we wanted to make > sure that the DID Document followed the normative requirements in DID > Core as well as those layered in the did:key Method specification. > > I've put the text above in the issue tracker, in the issue you raised. > Thanks for the clarifications, Markus... it's good to see progress > across all of these areas. :) > > -- manu >
Received on Monday, 29 August 2022 16:04:00 UTC