tools: remove unneeded temp directory handling

[Trott]

Checklist

• tests and code linting passes
• the commit message follows commit guidelines

Affected core subsystem(s)

test tools

Description of change

The handling of temp directory creation happens in common.js now so
there is no need to test the creation of the temp directory in test.py.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/2192/

[joaocgreis]

This was discussed in #3325 .

In common.js I found a mkdir for the test dir, but only the last one in the path (just the thread number if testing with -J). Is there one for the whole path?

[jbergstroem]

@Trott: can you point me to where it's happening? Afaik its only the thread folders, not the actual dir the thread folders lives in.

[Trott]

Is there one for the whole path?

No, but I can add one as part of this PR, and then see how review of this PR goes. (I assume there's general support for reducing the amount of Python code we rely on in exchange for more JavaScript code, all other things being equal.)

[Trott]

@joaocgreis OK, mkdirp implemented as part of common.js. Worked for me when I changed common.tmpDir to have a few extra 'tmp's in the path. In other words:

exports.tmpDir = path.join(testRoot, 'tmp', 'tmp', exports.tmpDirName);

PTAL

[Trott]

@jbergstroem If I'm understanding your question correctly, the mkdirp() implementation is now where that will happen.

[joaocgreis]

I assume there's general support for reducing the amount of Python code we rely on in exchange for more JavaScript code

That is not my opinion. Even if our test runner is somewhat confusing (to be nice), I like having something very stable to run the tests, because the node executable we test can be somewhere between release quality and completely broken.

[jbergstroem]

@Trott yes, but that also assumes that the parent directory exists. I actually used that same code path in a prior version of the patch but it ended up being much cleaner when implemented in test.py.

Edit: didn't see your patch. I'm kind of "if it works..." with this to be honest. Happy to replace test.py at some stage but I don't see a big win in moving it to common.js.

[Trott]

Sounds like there's support for simplifying/improving/replacing test.py but that this is not a win. Closing.