Add code coverage tooling

[jackson-at-bentley]

npm run test:standalone

I chose nyc because other projects at Bentley like ecschema2ts use it. If I configured everything correctly, the synchronizer has about 40 percent line coverage.

This is a breaking PR, but I don't think any projects depend on the v3 @itwin/connector-framework yet.

• I merged my branch as-a-user which passes the connector class object to the connector runner. I wasn't able to get the tests to run otherwise. This indirectly resolves ConnectorRunner should not invoke require in loadConnector #40. The tests failed to open the path given to require. I really have no idea what's going on, but I suspect that because nyc depends on ts-node for JIT complication it wasn't building the connector TypeScript.
• I installed mocha-suppress-logs to suppress the Logger output.
• I rearranged the project structure to make mocha happy. test is now in the root directory.
• I added a Coveralls GitHub workflow.

To address

• The HTML reporter fails to correctly link to the source files. I've opened an issue on nyc, but the text reporter works as shown above.
• npm run test:connector is failing with fetch is not defined. That code hasn't changed, and isn't covered by the tests [Figure 1].
• npm run test:integration is failing only on Linux with Failed OIDC signin. Looks like something is not right. Please contact your administrator. 400 - Invalid client_id. There's this very suspicious comment in oicd-signin-tool [Figure 2]. This also happens on the main branch on Linux.
• We shouldn't need to compile everything in the test directory because of the ts-node JIT tooling, but I'm not sure how else to configure nyc.

I've never configured coverage tooling before so I welcome any and all feedback.

What's next

• I'd like to add coverage standards to our integration, and maybe a service like coveralls for visibility.
• I think we really need an import style standard.

Figures

Figure 1

Figure 2

// Launch puppeteer with no sandbox only on linux
let launchOptions = { dumpio: true }; // , headless: false, slowMo: 500 };
if (os.platform() === "linux") {
    launchOptions = {
        args: ["--no-sandbox"], // , "--disable-setuid-sandbox"],
    };
}

[jackson-at-bentley]

Annotated.

[jackson-at-bentley]

A few miscellaneous changes.

[jackson-at-bentley]

This repository still won't build if linked externally. This import resolves the missing ws types that core-backend version 3.2.4 depends on.

node_modules/@itwin/core-backend/lib/cjs/LocalhostIpcHost.d.ts:4:21 - error TS7016: Could not find a declaration file for module 'ws'. '/home/jackson/bentley/connector-demo/node_modules/ws/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/ws` if it exists or add a new declaration (.d.ts) file containing `declare module 'ws';`

4 import * as ws from "ws";

[jackson-at-bentley]

I think we should be using strict mode.

[akshay-madhukar]

Why is this a breaking change? Adding code coverage tooling shouldn't change the exported members right?

[jackson-at-bentley]

Why is this a breaking change? Adding code coverage tooling shouldn't change the exported members right?

It changes the API for the connector runner.

[jchick-bentley]

@jffmarker @akshay-madhukar @admccarthy1 Jackson did a lot of refactoring around this connectorFile: string to avoid the require call (see ConnectorRunner.ts line 357). We looked through nodeApp.ts and see the code is presently set up to read the sourcePath from environment variables and set this as one of the jobArgs. So, it seems that if we approve this change, we will have to move the require call (or something equivalent) upstream to nodeApp.ts. Seems like a big change at this stage. Is there benefit to moving this out to NodeApp.Ts? Are there other orchestration workflows that also expect to pass a relative path to the .js connector source? These would also need to be updated to do the require call as well.