Currently the reference implementation, targeted at Node.js, has tests written in Jest. This was done purely to give me something to sanity-check my work as I wrote the spec. (I.e., I didn't want to write a spec with no check that it was correct.)

But for a web platform feature, what we really need is web platform tests, targeted at the built-in implementation.

Right now @hiroshige-g is using some clever hacks to run the reference implementation tests in Chromium. (See e.g. this CL.) This is not tenable longer-term, because:

• It is not reasonable to put the burden on future browser/spec engineers, besides myself and @hiroshige-g, to learn Jest and a wrapper framework to maintain this feature.
• It relies on Chromium-internal APIs for getting the parsed import map and resolving a module specifier.

So eventually, someone (ideally me, since I created this mess) should figure out how to port tests to idiomatic web platform tests. Here are some initial thoughts on that:

• Parsing tests:
  • The easiest way is to add some method of getting the parsed import map. This could be a standardized test-only API (using webdriver) for now, similar to e.g. this for the permissions API.
  • Eventually per Provide read-only access to the parsed mapping object #128 this could be exposed to web developers.
  • We could do limited porting without test-only APIs. For example complete parsing failures are catchable using <script>.onerror. Parsing successes can be tested to see if the resolution succeeds in the expected way. Individual parsing failures could similarly be tested by seeing if the resolution fails. This sounds like a good amount of work, but it may be worthwhile in the name of getting more integration test coverage...
• Resolving tests:
  • This would be easy if we had import.meta.resolve(); see How could import.meta.resolve() behave? #79.
  • Again a standardized test-only API is possible in the meantime.
  • I suspect there is some clever way to get the resolved URL of a module specifier today, as long as you're willing for it to be async. I need to think about it harder.

A goal then would be to have some kind of wrapper that allows running the tests against Node.js implementations like the reference implementation, so that we can continue to co-evolve the spec and reference implementation, like we do with Streams, URL, and the data: URL parser today. This works best, we've found, if we can make the test inputs a JSON data file.

I welcome thoughts or comments on the above. I think the next steps are for me to see if I can rewrite a few basic tests in non-vendor-specific, idiomatic web platform tests format.