You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are attempting to redesign the testing harness for this repository as a potentional
model for other repos as well. Jest has shown lots of trouble with ESM modules and
they seem unwilling to update it without experimental flags. I am motivated by node:test
which is built in as a testing framework and has no issues with ESM modules. For interface or
database mocking that might escape node:test, we will consider other well-supported libraries.
In several places, instead of test files, there are case descriptions in .testcase.md files.
These will be converted into test files that will be run by node:test. The .testcase.md files
will be removed after the conversion.
This application has some light web interfaces that will need checking. Elements and basic
interaction should be tested and available. Something like Playwright or Puppeteer may be
appropriate for this. We will need to investigate which one is better supported and easier to
use with node:test.
This application is also an API server. We will need to test the API endpoints.
We need to separate the availability of the API from the actual functionality of the API.
Prodigious use of mocking will be required to test the API functionality without needing to have
the entire application running. We will need to investigate which libraries are best for this
and how to use them with node:test.
Internal logic will need to be unit tested and have some integration testing when they are chained
together to perform a task or feed an API endpoint. We will need to investigate which libraries
are best for this and how to use them with node:test.
node scripts should be used with testing tags to let local devs run simple tests quickly and
confidently without needing to connect to databases or have the entire application running.
When commits are made or PRs are opened, the full test suite should be run to ensure that
nothing is broken. We will need to investigate how to set this up with GitHub Actions.
Activity
cubap commentedon Apr 13, 2026
We are attempting to redesign the testing harness for this repository as a potentional
model for other repos as well. Jest has shown lots of trouble with ESM modules and
they seem unwilling to update it without experimental flags. I am motivated by node:test
which is built in as a testing framework and has no issues with ESM modules. For interface or
database mocking that might escape node:test, we will consider other well-supported libraries.
In several places, instead of test files, there are case descriptions in .testcase.md files.
These will be converted into test files that will be run by node:test. The .testcase.md files
will be removed after the conversion.
This application has some light web interfaces that will need checking. Elements and basic
interaction should be tested and available. Something like Playwright or Puppeteer may be
appropriate for this. We will need to investigate which one is better supported and easier to
use with node:test.
This application is also an API server. We will need to test the API endpoints.
We need to separate the availability of the API from the actual functionality of the API.
Prodigious use of mocking will be required to test the API functionality without needing to have
the entire application running. We will need to investigate which libraries are best for this
and how to use them with node:test.
Internal logic will need to be unit tested and have some integration testing when they are chained
together to perform a task or feed an API endpoint. We will need to investigate which libraries
are best for this and how to use them with node:test.
node scripts should be used with testing tags to let local devs run simple tests quickly and
confidently without needing to connect to databases or have the entire application running.
When commits are made or PRs are opened, the full test suite should be run to ensure that
nothing is broken. We will need to investigate how to set this up with GitHub Actions.