Mock "exit" in "process"

[mjesun]

Since functions exposed in process are the real ones, exit is being exposed as-is. The issue is that calling process.exit with a zero exit code might trick the workers, thinking the execution was stopped.

Pretty much like we do with send, we will override it with an empty method that does nothin.

[SimenB]

Missing changelog :o

[SimenB]

Should probably update the text in #6714 as well to say "blocked" or "stubbed" or something

[mjesun]

@SimenB I wasn't aware of this, that's pretty cool! What do you think about moving the code snippet in #6714 into the create_process_object.js file, then avoid doing the realExit? I'd also like to extend the error message saying that in order to capture the error you should mock the function via jest.spyOn(process, 'exit').mockImplementation(() => {...}).

[SimenB]

I left out the first part since we need access to config to properly format stack traces (e.g. rootDir for relative paths). Happy to move it there if you think it's ok to pass config through

[mjesun]

I've been thinking that once you reach process.exit, you probably don't expect anything else to get executed; should we just throw instead? Then we can provide the mocking help in the exception as a UX thing.

[mjesun]

(Or, even better, we should probably throw to abort test execution, then capture this thrown value and silently pass. It would probably be the closest behavior to process.exit without exiting).

[thymikee]

Makes sense.

[mjesun]

@thymikee which one of the two? 😄

[thymikee]

Hah, I was replying to the first one. I'm just not sure about silently passing process.exit – when you do so, you expect the program to stop executing asap, no?

[mjesun]

Yes, but code is being executed in the Jest sandbox. My gut feeling is that you expect your test to be finished, but not killing the entire worker.

[thymikee]

Yup, but throwing wouldn't kill the worker, just fail the whole test suite, or am I missing something?

[mjesun]

The way I see it is that we'd catch this "special error" thrown (e.g. a Symbol), and silently pass the test.

[thymikee]

And then re-throw if it was not-0? Or display a warning that process.exit was called and do something about it?

[SimenB]

I don't see any use case for process.exit to exit the test run or worker. I'm down with throwing and failing the whole suite though, and providing a nice message about how to mock process.exit if people wanna use it

[mjesun]

The issue I see if we follow that approach is that mocking process.exit won't interrupt the code execution, as it would hapen on a real-life scenario. The only way I can see of stopping test execution is to throw and silently catch, but having to tell the user to do that by default is kinda overengineering.

[SimenB]

I think #6714 covers this. Reopen if you disagree 🙂

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.