jacoscaz / quadstore

A LevelDB-backed graph database for JS runtimes (Node.js, Deno, browsers, ...) supporting SPARQL queries and the RDF/JS interface.
https://github.com/jacoscaz/quadstore
MIT License
197 stars 14 forks source link

Modernize test suite #150

Closed jacoscaz closed 1 year ago

jacoscaz commented 2 years ago

Upcoming performance work in #115 will require a significant amount of tests. Quadstore's test suite dates back to the first few releases and needs to be brought into the present before it becomes too big to be refactored.

TODO:

rubensworks commented 2 years ago

Figure out how to programmatically run the test suite browser-side

Please keep me posted on this. We should eventually have a similar thing for comunica :-) Perhaps https://www.npmjs.com/package/@web/test-runner may help.

jacoscaz commented 2 years ago

Please keep me posted on this. We should eventually have a similar thing for comunica :-) Perhaps https://www.npmjs.com/package/@web/test-runner may help.

I had already started thinking along similar lines; the idea would be to actually ship the test suite as a separate web application to be bundled into a single ES module with Webpack and then loaded browser-side via puppeteer.

jacoscaz commented 2 years ago

Note to self: the testing framework should not depend on a CLI tool (mocha, jest, ...) but ship as a library supporting multiple JS runtimes (tape could be a good candidate).

jacoscaz commented 2 years ago

I think I've found a decent way forward with mocha. I've prototyped it at https://github.com/jacoscaz/isomorphic-testing-demo . @rubensworks

rubensworks commented 2 years ago

@jacoscaz Interesting! Do you think this approach would only work with mocha? Or would jest also work?

jacoscaz commented 2 years ago

Insofar as I can understand Jest doesn’t officially support running in browsers whereas mocha and jasmine (amongst others) do. There’s likely a way to do it but it may also be impractical. This approach should be generalizable to any framework that can be used browser-side.

jacoscaz commented 1 year ago

Done! With today's work, tests always run both server-side (via the usual mocha cli tool using the ClassicLevel and MemoryLevel backends) and browser-side (using the BrowserLevel and MemoryLevel backends). To achieve the latter the test suite is compiled using tsc, bundled up using webpack and then loaded browser-side using puppeteer; the overall outcome (total and failures) is relayed to the node process by means of the window.__TEST_RESULTS__ variable, later queried via puppeteer.

Pinging @rubensworks and @gsvarovsky.