Rearm of tests

[yankos]

• Update GitHub action;
• Rearm tests of serializators: only scalar data types should be tested;
• Improve a documentation how to run test manualy;
• The Codecoverge integration.

[oberstet]

ahh, nice, thanks for contributing! I had a look, just 1 question (curious): you don't like BigInt? any reason? thing is: I seem to remember this was specifically related to some blockchain use case. not sure though, some time ago ..

essentially, could you explain why the PR removes these tests?

                // UTC of today
                BigInt('1558266424841951553'),
                // 2**255-1 : NotImplementedError TODO: TAG BIGNUM for bigger bignum bytes_info=24, len(ull)=8
                // BigInt('57896044618658097711785492504343953926634992332820282019728792003956564819967'),
                BigInt('340282366920938463463374607431768211455'),
                Uint8Array.from([0, 1, 2, 3, 4, 5, 6, 7]),
                randomBytes(32),
                {a: 5, b: "hello2", c: randomBytes(32)}

[yankos]

I would like to keep it, but I removed BigInt because it cannot be serialized directly by JSON. So I think it's better to keep only types that can be serialized directly (not just for JSON).
Maybe I'm wrong?

[oberstet]

because it cannot be serialized directly by JSON

yes, true, but then how do you deal with e.g. blockchain stuff (which requires big ints) without faking with strings or what, and msgpack and cbor support it - and those are preferred anyways (IMO).

keep only types that can be serialized directly (not just for JSON).

why use the worst/least capable as reference and basically make all other follow that?

Maybe I'm wrong?

yep (IMO). I would prefer keeping big int, and then of course keep the relevant tests as well. I can't merge a PR that removes it because AutobahnJS is used with blockchain stuff (at least in the context of Crossbar.io) ..

pls keep all tested values exactly as is in

autobahn-js/packages/autobahn/test/test_binary.js

Line 67 in 1f8d7f1

var vals1 = [

did you test XBR? unlikely, it's yet another level of complexity. but I'd be worried about this .. unfort., I'm working on sth completely different right now, can't test myself, so I would opt for a very conservative approach "checking" a PR - only absolutely obvious things, or stuff moving deps forward, ..

[oberstet]

another way to say what I mean: pls keep and test the full power/features of CBOR. I don't care much about JSON. well. should continue to work of course, but feature parity between all serializers is not a goal. use CBOR, dump JSON, is the sane thing IMO anyways for app developers

[oberstet]

also, after relooking:

pls keep .crossbar/key.* as well. I seem to remember some tests assume CB keys present (those are just throw away keys, no security worries. of course normally this isn't recommended on GH repos, but ..).

next: CODECOV_TOKEN .. well, I would need to setup that I guess and all. trouble. is it worth it? I wouldn't rely on / look at "coverage reports" anyways? would you?

c8": "^8.0.1",: what's that? some new JS stuff? my experience: every dep introduces problems, if only keep it rolling. what's the value?

test_binary_cbor.txt and similar: those are the "known good" target/desired outputs of tests. since I right now can't run myself, I'd like to keep those as well. CBOR (the spec) hasn't changed, so there cannot be a valid reason to change those. I mean, other than strictly new lines. if new tests are added. the existing serialized values should be kept.

I know, this might all sound strange, strict or annoying. well, JS is annoying, so I like to keep things as static as possible - unless you can prove there is a bug of course!

is there a bug?

sorry, and thanks a lot for contributing, pls don't feel offended or put off or sth!

[yankos]

pls don't feel offended or put off or sth!

I did not even think about this :)

But let's step by step.

next: CODECOV_TOKEN .. well, I would need to setup that I guess and all. trouble. is it worth it? I wouldn't rely on / look at "coverage reports" anyways? would you?

c8": "^8.0.1",: what's that? some new JS stuff? my experience: every dep introduces problems, if only keep it rolling. what's the value?

c8 is a code coverage tool. I removed the Codecov.io integration. However, I would like to keep c8 as an optional tool. It's useful when you're working with a library and don't know every line in the source code.

pls keep .crossbar/key.* as well. I seem to remember some tests assume CB keys present (those are just throw away keys, no security worries. of course normally this isn't recommended on GH repos, but ..).

Maybe I am missing something, but these keys are instance/host-specific. So I can't run the tests anywhere (except your intel-nuci7) without removing the key.* files.