build: add js lib tests to ci

[subotic]

• Adds running of the knora-api-js-lib tests to the Makefile and Github CI
• the passing of these tests cannot be made mandatory knora-api, because the dependency is the other way around. The reviewer, before approving a PR, needs to make sure, that a PR is in place and ready for merging in knora-api-js-lib.
  --
  resolves Generate client code and run Tests in knora-api-js-lib automatically #1554
  resolves Change CI to use private repository instead of encrypted files #1599

[subotic]

The JS Lib Tests test is failing because there are some missing changes from a pending branch in knora-api-js-lib that provides the code that is missing. The branch in knora-api-js-lib can only be merged if this branch gets merged first.

[tobiasschweizer]

FAILED TESTS:
2457
  ResourcesEndpoint
2458
    method createResource
2459
      ✖ should create a resource with values
2460
        HeadlessChrome 80.0.3987 (Linux 0.0.0)
2461
      Error: Expected $['http://0.0.0.0:3333/ontology/0001/anything/v2#hasDecimal']['http://api.knora.org/ontology/knora-api/v2#decimalValueAsDecimal']['@value'] = '1.5' to equal '100000000000000.000000000000001'.
2462
          at <Jasmine>
2463
          at UserContext.<anonymous> (src/api/v2/resource/resources-endpoint.spec.ts:243:36 <- src/api/v2/resource/resources-endpoint.spec.js:290:48)
2464
          at <Jasmine>
2465

This is a problem with precision in JavaScript (dasch-swiss/dsp-js-lib#126). Until this is fixed, the test data for "http://0.0.0.0:3333/ontology/0001/anything/v2#hasDecimal" should be something whose precision can be correctly represented without an additional lib. Maybe you can ask @benjamingeer to change the test data for now.

[tobiasschweizer]

So far, I have just fixed this manually in the test data. But because your tests generate everything automatically, this hack fails here.

[tobiasschweizer]

@benjamingeer @subotic I think all that has to be done to make this PR work is changing the test value for http://0.0.0.0:3333/ontology/0001/anything/v2#hasDecimal in "v2/resources/create-resource-with-values-request.json" from "100000000000000.000000000000001" to "1.5". The precision issue will be dealt with in dasch-swiss/dsp-js-lib#126 and additional unit tests can be added to check for the correct handling of precision, but those could be independent from Knora (no additional generated test data needed).

[benjamingeer]

@tobiasschweizer That request is also used to test Knora. I thought that was the whole idea here: we use the same request to test Knora and to test the client code. If we change it to 1.5, we're not testing Knora's handling of decimal precision.

[tobiasschweizer]

That request is also used to test Knora. I thought that was the whole idea here: we use the same request to test Knora and to test the client code. If we change it to 1.5, we're not testing Knora's handling of decimal precision.

I understand. So should we patch the test data after its generation until dasch-swiss/dsp-js-lib#126 is done?

1. generate test data
2. parse JSON
3. manipulate the value in question
4. serialize it back

I think I could write a script that could be called from npm run.

[benjamingeer]

@tobiasschweizer How about just disabling that test until dasch-swiss/dsp-js-lib#126 is done?

[tobiasschweizer]

The problem is that this affects the test for resource creation: https://github.com/dasch-swiss/knora-api-js-lib/blob/da6f34514f33e64d1734ae9d2d37c21f958be2af/src/api/v2/resource/resources-endpoint.spec.ts#L111-L245

It's not a test that is specific to decimal values.

[benjamingeer]

The problem is that this affects the test for resource creation

OK, but it seems to me that if you can't create a resource with a decimal value, you can't create a resource, so that test should fail or be disabled.

[tobiasschweizer]

Let's say that I give it a try and if it takes too much time to write the script, I will think you disabling the test.

[tobiasschweizer]

if you can't create a resource with a decimal value

You absolutely can. The problem is just that precision is lost in JS with the given decimal number.

[benjamingeer]

The problem is just that precision is lost in JS with the given decimal number.

But that's a bug. If there's a bug, then I think the test should fail or be disabled.

[tobiasschweizer]

But that's a bug. If there's a bug, then I think the test should fail or be disabled.

It's the way JS can handle precision without any additional libraries or workarounds.

[benjamingeer]

It's the way JS can handle precision without any additional libraries or workarounds.

I could imagine various ways of dealing with this in JS, including using a string rather than a number. But from the user's point of view, that's irrelevant. If the resource creation test passes, the user should be able to trust that they can create a resource with any value type and get the expected result. If that's not true, the test should fail.

[subotic]

@benjamingeer thanks for the review :-) I will merge this. Whatever else needs to be done, can then be done in a different PR.