Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Node's built-in test runner for tests that don't need to be run in a browser #1306

Merged
merged 55 commits into from
Jan 29, 2024

Conversation

bhousel
Copy link
Contributor

@bhousel bhousel commented Jan 24, 2024

I've been working with @tannerwuster for the past week on an experiment to convert some of our tests from executing under karma/mocha to using Node's test runner, available in Node v18 and newer. The experiment has been going pretty well, so I'm opening a PR for visibility.

In order to make this work, I needed to create a separate file that only exports the parts of code that can be run "headless" (i.e. no browser). When running in node, there wont be things like window, document, navigator, etc. But what we can do is run plain Javascript code significantly faster, and use the c8 tool to gather detailed code coverage numbers:

Screenshot 2024-01-24 at 2 41 01 PM

There are a few reasons why it makes sense to do this work now:

bhousel and others added 20 commits January 12, 2024 11:36
We can use node:test to run unit tests for situations where we don't
need the tests to run in a browser with karma, which we will be replacing.
I started looking into using node:test for our unit tests and learned that
node requires this.

Other environments like Typescript, or bundlers like rollup/esbuild/webpack/
or CJS imports, in the past have been more forgiving of skipping the file
extension, and they will automatically add the '.js' or look in 'index.js'

Node import with ES modules will not do this, for reasons.
(it actually mimics the behavior of imports in a browser environment)

So going forward, we should just always include the full path and extension
for all local file imports.

see also
https://stackoverflow.com/questions/72491392/when-do-we-need-to-add-file-extension-when-importing-javascript-modules
Also created "headless.js" for code that can run without a browser.
We may need a esbuild step for this eventually, but for now this is all code
that should be able to run directly in vanilla JS / node with no complication step.
Introducing async in these tests was unnecessary and adding a bit of overhead.
We found that just running the tests synchronously makes them a bit faster.
Also remove a few more of the unnecessary async/await
Also in intersection.js, add explicit `true`/`false` for `only` and `no`
Before, it would just leave them `undefined` if they were unmatched.
@bhousel
Copy link
Contributor Author

bhousel commented Jan 29, 2024

This is going pretty well and we were able to convert over the tests from

  • actions/
  • geo/
  • lib/
  • osm/

I'm going to merge what we have so far to avoid the branch from going on too long and conflicting other things.

For next steps I'd like to attack:

  • the validator
  • core systems (but not UI)
  • core services (these generally fetch data and handle responses, we are already mocking fetch in our tests)

This is work that we can spread out and do over time. Improved testing of the validator would be the most impactful one.

@bhousel bhousel merged commit c0fea38 into main Jan 29, 2024
1 check passed
@bhousel bhousel added this to the v2.2.5 milestone Feb 9, 2024
@tannerwuster tannerwuster deleted the node_test branch May 31, 2024 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants