Add key type tests

[aljones15]

Refactors the test suite so a common set of assertions runs on all the curves and not just one of them.

Addresses: #34

[dlongley]

This one needs to be reverted back to EcdsaSecp256r1VerificationKey2019. This is for backwards compatibility tests. The others should be Multikey as they are now.

[aljones15]

Reverted here: 28c76f3 but that breaks the id should be set test so will need to further revise this PR.

[aljones15]

@dlongley ok so inside of the multkeys map in mock-data I now set the type to Multikey so the P-256 one will pass the should set id test: https://github.com/digitalbazaar/ecdsa-multikey/pull/35/files/28c76f394ed4919f39581d2fdc60611810a2dd92..09a57e00aeebfdc1d25a6e6eee4c64273e64a5ff

Should we test both the backwards compatible EcdsaSecp256r1VerificationKey2019 P-256 and the Multikey P-256? if so I'm assuming for EcdsaSecp256r1VerificationKey2019 the id is not set by default?

This is the test that is failing

ecdsa-multikey/test/assertions.js

Lines 173 to 178 in 09a57e0

	it('should auto-set key.id based on controller', async () => {
	const {publicKeyMultibase} = serializedKeyPair;
	const keyPair = await EcdsaMultikey.from(serializedKeyPair);
	_ensurePublicKeyEncoding({keyPair, keyType, publicKeyMultibase});
	expect(keyPair.id).to.equal(id);
	});

for EcdsaSecp256r1VerificationKey2019

[dlongley]

@aljones15, we shouldn't hack the key type to be Multikey just to pass this test. Either the library is supposed to auto-generate an id no matter what the key type was, or it shouldn't do it for a key type of EcdsaSecp256r1VerificationKey2019. For now, I'd say to skip this test if the key type isn't Multikey and file an issue to possibly add id auto-generation for other key types.

[aljones15]

@dlongley not sure I hacked the key type to be Multikey as by default generate({curve: 'P-256'}) produces a key with type Multikey. All the test suite does is ensure that all keys in the multikeys mock-data map have type Multikey. The original EcdsaSecp256r1VerificationKey2019 is not mutated and still exists in the suite. The question is should we test both P-256 Multikey and P-256 EcdsaSecp256r1VerificationKey2019, the answer to that appears to be file an issue about it for now as EcdsaSecp256r1VerificationKey2019 does not pass all the tests.

[aljones15]

issue created here: #36 for EcdsaSecp256r1VerificationKey2019 in test suite loop and and key id generation.

[dlongley]

All we want with the EcdsaSecp256r1VerificationKey2019 key pair is to demonstrate that we can import and use it like any other keypair. It exists so we can run tests against legacy key pairs that use that type. So as long as this PR includes some tests against something that imports using that key type, we're good. That doesn't have to include id generation at this time.

[aljones15]

@dlongley the original key type import tests were left as is:

ecdsa-multikey/test/EcdsaMultikey.spec.js

Lines 66 to 77 in 09a57e0

	describe('Backwards compat with EcdsaSecp256r1VerificationKey2019', () => {
	it('Multikey should import properly', async () => {
	const keyPair = await EcdsaMultikey.from(mockKeyEcdsaSecp256);
	const data = (new TextEncoder()).encode('test data goes here');
	const signature = await keyPair.signer().sign({data});
	expect(
	await keyPair.verifier()
	.verify({data, signature})
	).to.be.true;
	});
	});

[dlongley]

Ok, sounds good.

[dlongley]

I'm not sure about this style, but I don't have a better suggestion for reuse that is as succinct, so I'm going to approve and merge this. It's hard to tell that everything was preserved so I'm just assuming it is -- and maybe some codecov printout will tell us that things still get the same or better coverage somewhere.

[dlongley]

Thanks! Going to merge this now.