lightningcss icon indicating copy to clipboard operation
lightningcss copied to clipboard

Suggestion on Expanding Node.js tests

Open drwpow opened this issue 8 months ago • 0 comments

Hello! I was looking at some of the open issues and would love to start submitting bugfixes. But looking at the test suite for Node.js I think it would help contributors like myself if we expanded the test setup to more easily allow slotting in new test cases.

Of course touching tests can get dicey! And we want to improve coverage, not destabilize. So I wanted to talk through a strategy. Here’s what I’d like to propose, but happy to change any of these points

  • Use Vitest. uvu was great, but Vitest supports full ESM, TypeScript, doesn’t require full builds, and can run Node + browser tests simultaneously. As it’s now a standard testrunner in many OSS libraries it would be more familiar to most

  • Use test.each(). In libraries like this where there can be so many layers, testing the entire surface (Node.js + wasm) gives the best “bang for the buck” but only if there are a lot of itty-bitty inputs and outputs.

    Testing individual layers can be easy to grok but it requires duplicating tests for every layer, and sprinkling in integration tests between layers multiply tests further.

    Mega E2E tests that produce large outputs aren’t great at tiny bugfixes.

    E2E tests that also require lots of boilerplate setup, and lots of granular assertions, also are complex because the coverage isn’t easy to understand at-a-glance what’s tested and what’s not, especially in such a complex system.

    But testing tiny inputs, tiny outputs of the whole thing is the perfect blend of minimal test maintenance + maximum coverage for micro/behaviors. I’d love to introduce a setup closer to that.

  • Using just as a wrapper. I really like the test setup of Biome.js and Rolldown that do more automated setup of the tests where you can be more confident running tests locally matches CI. This is more of a DX thing, but given other OSS projects seem to have smoothed over a lot of these tools, aligning could yield benefits.

  • Not touching Rust tests (for now). The changes I’d like to propose would be ONLY for Node.js tests. Perhaps we decide to make the Rust tests easier to run for folks that aren’t Rustaceans, but IMO those tests are fine and great as they are.

    Should also note that there are a lot of existing Node.js tests that capture a lot of behavior that should be 100% preserved! And for existing tests of course I’m only suggesting a reorganization but not losing any existing coverage. Only making the test suite simpler for folks to extend.

Do you have any thoughts about this? Supposing this plan sounds good, I was thinking we could do something like the following:

  1. Convert to Vitest with as few changes as possible
  2. Dedupe common setup/test fixtures (test helpers)
  3. Separate fixtures from assertions (ideally using more files, organized in a logical way that mirrors the API)
  4. Add just to run Node.js + Rust tests together

All suggestions, all open to change. Thanks for a great library!

drwpow avatar Apr 20 '25 16:04 drwpow