Repository navigation
Allow running all tests in the same process #48871
Description
What is the problem this feature will solve?
I can't share the same server instance (or everything else) between test files
This is needed as I want to use the same server between tests like in production, this also make tests slower as we need to re-evaluate all the modules again
What is the feature you are proposing to solve the problem?
Allow running tests in the same process = no isolation (which will also force concurrency 1)
(concurrency 1 won't mean isolation l, but isolation: false, do...)
What alternatives have you considered?
There is none that I can think of
Activity
bnoordhuis commentedon Jul 22, 2023
That introduces non-determinism (read: heisenbugs) because tests can clobber the runtime environment. I see only downsides unless you enjoy pain.
rluvaton commentedon Jul 22, 2023
For stateless application I don't see a problem, a lot of people using it when they use mocha (vitest allow you to by disabling isolation) and I personally have used it in my company for above 5 years for couple of production, big (some became monolithic) repositories and no problem at all so far
MoLow commentedon Jul 22, 2023
well, the implementation would be requiring/importing all your test files, and simply executing them.
I don't really see any reason to implement that inside core, since it is pretty trivial to import a list of files.
rluvaton commentedon Jul 22, 2023
But you lose all the reporting functionality, no?
MoLow commentedon Jul 22, 2023
No. Reporting works without --test
bnoordhuis commentedon Jul 27, 2023
I believe the consensus here is "no" so I'll go ahead and close this out.
adrian-burlacu-software commentedon Sep 26, 2023
Just leave it on one thread like literally the whole language and follow KISS! you can't dictate what singletons -- e.g. clearing test data files, SQLite contention, admin security -- need to be tested by one test at a time. All this current implementation does is force me to write the whole test suite into one file.
The real reason that I think you prefer the child process approach is because of the isolation and not race conditions. I know Mocha and Jest use different isolation that clears up global state and they run the tests one at a time.
bnoordhuis commentedon Sep 26, 2023
Your post is so rambling and incoherent I don't know if you're trying to make a point, let alone what point.
adrian-burlacu-software commentedon Sep 27, 2023
FTFY
bnoordhuis commentedon Sep 27, 2023
That's indeed pretty much what I said.
I don't know what mocha does but I'm passingly familiar with jest and it's built on a pretty shaky foundation (
vmmodule hack, basically.)adrian-burlacu-software commentedon Sep 27, 2023
One other thing that would butter all the biscuits: just run and wait on the child process until it ends the current suite, then spawn another one instead of spawning all of them at once...I'd do it but I have 0 XP on building Node itself and 0 time -- need a paid job.
bnoordhuis commentedon Sep 28, 2023
A
--serialflag? Doesn't seem objectionable to me but it's better to open a new feature request for that.rluvaton commentedon Sep 28, 2023
@MoLow So I tried just importing the files but then you lose some critical features such as test timeout.