Run unit test without --once flag

minhna · October 15, 2026, 10:04am

I tried to run unit test with Meteor version 3.5.2 (rspack enabled). When I remove --once flag, the test run keeps loading over and over again. Do you have solution for this problem?

xet7 · October 15, 2026, 10:08am

@minhna

WeKan has many tests, that are run with build.sh and build.bat . Maybe looking at those could help?

grubba · October 15, 2026, 6:13pm

Hi, @minhna are you running meteor in the same folder?

Two runs could trigger each other.

Would you be able to share a small repro repo? I tested locally, and I could not reproduce it(testing on a Mac)

minhna · October 16, 2026, 12:33am

Thank you. That’s the problem. I run the app and test the app on a different port.

minhna · October 16, 2026, 12:36am

Thank you. I found the issue: the app was running on a different port.

grubba · October 16, 2026, 6:48pm

Nice that it is sorted!

I’ve asked some of my bots to take a look and it seems like the whole reason for the issue is that both runs still share the app’s _build folder (which is an issue , fix in review). If you want to run the app and tests at the same time, give the test run its own local dir:

METEOR_LOCAL_DIR=.meteor/local-test meteor test --driver-package meteortesting:mocha --port 3100

minhna · October 17, 2026, 10:42am

adding METEOR_LOCAL_DIR env doesn’t solve my re-loading problem.

minhna · October 17, 2026, 10:52am

When I run meteor test, it adds these packages in .meteor/versions file:

meteortesting:browser-tests@1.8.0
meteortesting:mocha@3.4.0
meteortesting:mocha-core@8.2.0

But when I run the app `meteor run` it removes those packages.

Do you have any idea @grubba ?

nachocodoner · October 19, 2026, 11:07am

Thanks for the extra details @minhna. Running the app alongside tests should work, and the .meteor/versions changes are a useful clue.

As @grubba mentioned, we have an open issue with a [fix under review](https://github.com/meteor/meteor/pull/14791) that we’re planning to include in an upcoming release. That addresses the shared Rspack files interfering with each other, but we still need to verify whether it also resolves your reload loop without --once. We’ll proceed on ensuring that.

Anyway, and to ensure we don’t miss any other further case, could you share a small repo that reproduces this, along with the exact commands you run in both terminals, any environment variables, and your OS? A reduced version of your app or a fresh Meteor 3.5.2 app is fine, as long as you’ve confirmed it shows the same behavior. It would also help to know whether the reload loop stops when you stop the dev server and leave the tests running.

That would help us check whether the existing fix covers your case or whether the .meteor/versions changes need a separate follow-up. Otherwise, we will let you know when the ongoing fix gets included for you to double check.

UPDATE

I reproduced the .meteor/versions changes you pointed out, including with a separate METEOR_LOCAL_DIR. The test command writes its extra packages into the shared version file, and the running app removes them again.

I’ve opened a follow-up PR building on Per’s scaffold fix, with an additional fix for the version-file conflict. The new core tests fail before that additional fix in both --once and watch mode, and pass after it. The watch case also verifies that tests rerun and the app updates after a source edit.

It’s still a draft targeting 3.6 and hasn’t been released yet. The local checks used filesystem polling, so I’d still like to confirm the full reload behavior with your setup before calling this resolved, in the next beta we include this fix.

github.com/meteor/meteor

fix: isolate concurrent app and test builds (#14848)

release-3.6 ← fix/concurrent-run-test-watch

opened 11:49AM - 19 Oct 26 UTC

nachocodoner

+406 -17

Fixes #14789 and covers the [forum follow-up about repeated `.meteor/versions` c…hanges](https://forums.meteor.com/t/run-unit-test-without-once-flag/64832). Running `meteor run` alongside `meteor test` in the same app can interfere through two shared files: the test command overwrites a rebuilt Rspack scaffold, and its transient driver changes the app's `.meteor/versions`. The normal app removes those test-only dependencies again, triggering further rebuilds even with separate `METEOR_LOCAL_DIR` values. This includes @perbergland's scaffold fix and regression test from #14791, preserving both original commits unchanged. The additional CLI fix keeps app-test package solutions in memory instead of writing them to the app's version file. Tests still read the app's existing version pins, and the runner retains the resolved test packages across rebuilds. `test-packages` continues to use its separate generated app. The new core E2E cases supply the Mocha driver only through `--driver-package` and cover both `--once` and watch mode beside a running app. They check version-file contents and modification time, test execution, and app responses. The watch case edits a shared module and requires the updated test to pass and the app to serve the new value. The existing CLI self-test also checks version-file stability for regular and full-app tests. Validation: - Before the additional fix, both concurrent cases fail because `.meteor/versions` is rewritten; the CLI test also fails because its transient driver is persisted. - After the fix, all 8 concurrent-mode E2E cases pass, including the original scaffold regression. - The watch case also passes a focused rerun with the final assertion requiring a passing result after the updated test marker. - The CLI self-test passes for regular and full-app tests. - All 6 `rspack - build-context` Tinytests pass. Local validation used filesystem polling because the host's inotify allowance was exhausted. Native filesystem notification behavior was not validated in this run.