Automated test for browser environment

[lenkan]

We need some sort of tests that verifies that the library is working properly in a browser environment. See PR #218 #214 for related issues.

There must be thousands of other examples out there with libraries that are supposed to work for both node.js and browser environments. But just to spark the discussion I have written down some thoughts below.

Let a bundler catch any node specific imports

One simple check that can be done is to try and bundle the entire library for a browser, then just discard the output. For example: (Note: this does not seem to catch if we are using the Buffer module)

npx esbuild src/index.ts --bundle --target=chrome58

Will fail because we have a dependency on the node-specific crypto module:

$ npx esbuild src/index.ts --bundle --target=chrome58
✘ [ERROR] Could not resolve "crypto"

    node_modules/ecdsa-secp256r1/index.js:1:23:
      1 │ const crypto = require('crypto')
        ╵                        ~~~~~~~~

  The package "crypto" wasn't found on the file system but is built into node. Are you trying to
  bundle for node? You can use "--platform=node" to do that, which will remove this error.

1 error

Configure eslint environment

It is possible to configure the eslint environment to catch usage of globals that are not available in both node and browser environments. https://eslint.org/docs/latest/use/configure/language-options. The setting is supposed to be shared-node-browser, but not sure if it works as I expect.

Running integration test suite in browser environment

It would be good to try and run the jest test suite in a browser environment. Not quite sure if this works, it could be that jest itself actually requires the node.js runtime environment.

Using an e2e test tool

Using an e2e test tool. For example

• Cypress https://www.cypress.io/
• Selenium https://www.selenium.dev/
• Playwright as mentioned here: Automated test for browser environment #219 (comment)
• Puppeteer https://pptr.dev/

One thing to keep in mind here is that we really only want to execute scripts and make sure they run. Most of these tools I think focus testing the DOM behavior. So we might be able to get away with something much simpler. I am thinking some way to just include a script in a dummy HTML document and wrap in it a try catch, then load the html in a headless browser using puppeteer might be the easiest way.

[edeykholt]

I've used https://playwright.dev/dotnet/ for testing a Blazor WASM extension and interaction with javascript pages, including in an automated CI/CD pipeline (Azure DevOps). Should work on this stack, as well?

[lenkan]

This looks like a promising tool, especially the headless option https://vitest.dev/guide/browser.html