-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add several tests for XI functionality. #5
Conversation
-tests for different XI values -tests for XI validation failures -test for docLoader passthrough using fake statically loaded context -no check vs static proof value: maybe need to hardcode ecdsa nonce?
Checking signing against static data would be an issue. But positive/negative verification tests could happen with static signed data right? Right now that is the same as checking lib against itself. But it might help catch regressions or be used as a test vector with another lib. |
Can you explain what you mean here? Positive/negative verification tests meaning what exactly? Signing the same thing twice and making sure it has the same proof value? Making sure signing different things results in different proof values? |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #5 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 7 7
Lines 86 86
=========================================
Hits 86 86 Continue to review full report in Codecov by Sentry.
|
I mean signed data is generated and stored as a test vector. Then the code has tests that verify against it. Similar to other tests with dynamically generated data. Have tests that verify it, and tests that use bogus extra info, or other issues, to check it doesn't verify. The idea being that will snapshot what signed should look like and catch changes. Like if some internal bug causes the library to verify against itself, hopefully the static data would fail. As you say, rechecking signing is more difficult due to it being non-deterministic. Although, could have some sort of test that signed data looks like a static value other than the signature. Not sure how far down the testing path this needs to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can merge this after minor style nit is addressed.
test/EcdsaXi2023Cryptosuite.spec.js
Outdated
type: 'DataIntegrityProof', | ||
created: '2023-03-01T21:29:24Z', | ||
verificationMethod: 'https://example.edu/issuers/' + | ||
'565049#zDnaekGZTbQBerwcehBSXLqAg6s55hVEBms1zFy89VHXtJSa9', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be indented 2 spaces ... I'd do a suggestion here but github won't let me for some reason.
test/EcdsaXi2023Cryptosuite.spec.js
Outdated
proofValue: 'z2Q8gjsP1zrCA8wLb6pErmGJic5Uw7723JAjXSTkdhib2' + | ||
'xoH4LBR49LnbijfhjVMm7NfKYYiQxF2tC6pgEmqq9MtZ' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be indented 2 spaces ... I'd do a suggestion here but github won't let me for some reason.
Fixes #2.