Skip to content

Conversation

sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Aug 30, 2025

This means that we can remove the loop over JS_ENGINES from few more
tests.

It also splits up these tests in to smaller units which is always good
and means that it much more obvious what is going on when one of them
fails.

suffix += 1
engine_mapping[name] = (engine,)

parameterize(metafunc, engine_mapping)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this not run the entire test in each engine, while before we built once and just executed the JS once per engine?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does work that way. This means that there will be slight slowdown for folks with multiple engines configured.

However:

  1. Configuring multiple engines is optional, and rare. None of CI setups do this.
  2. There are very few tests using this decorator (currently just 1 test on main, updated to 6 tests with [test] Use all_engines more consistently. NFC #25112).

Given upsides (separate names failing tests, avoiding inner loops in tests that make debugging hard), I think its worth it in this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, none of our CI setups test multiple engines? Don't we set up V8 on circleCI?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have CI tests that configure different engines, but never more than one engine at the same time.

@all_engines is a no-op unless you have multiple engines configured at the same time.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually this might not be totally true, I think for v8 we do configure it to be in addition to node (i.e. we append it to JS_ENGINES) but for jsc and spidermonkey testing we always just do JS_ENGINES = [spidermonkey] or JS_ENGINES = [jsc].

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But still, given how few tests run with all_engines I think this should be fine.

Also, of the 7 total tests that are currently marked with all_engines we can/should probably remove some of those annotations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, I guess it's worth the debuggability.

…tion. NFC

This means that we can remove the loop over JS_ENGINES from few more
tests.

It also splits up these tests in to smaller units which is always good
and means that it much more obvious what is going on when one of them
fails.
@sbc100 sbc100 force-pushed the all_engines_split_tests branch from 69abd2c to 14c37ff Compare September 3, 2025 18:24
@sbc100 sbc100 enabled auto-merge (squash) September 3, 2025 18:37
@sbc100 sbc100 merged commit 09365fd into emscripten-core:main Sep 3, 2025
27 of 30 checks passed
@sbc100 sbc100 deleted the all_engines_split_tests branch September 3, 2025 19:36
@sbc100
Copy link
Collaborator Author

sbc100 commented Sep 3, 2025

Oops this auto-merged even though there were failing tests.

Reverting for now and so I can re-land once I debug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants