Fix: Windows path parsing for JUnit (fixes #12507)

[thewalla07]

This commit aims to fix the issues described in #12507 by removing the
assumption that POSIX style filePaths are supplied by messages.

The tests for this are also updated to run on both Windows and POSIX
based systems. The results can be seen by running ESLint with the JUnit
formatter on a Windows system.

Full details can be seen in the issue mentioned above.

What is the purpose of this pull request? (put an "X" next to item)
This PR is a followup to fix a missed bug introduced in #11683 where Windows paths are not supported properly.
[ ] Documentation update
[X] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)
I changed the function pathWithoutExt(filePath) so that it does not assume POSIX style paths. Instead it will allow Node to determine which style of path to expect (POSIX or Windows) based on the OS.

From looking at the original PR it seems that this change to assume POSIX was done after the changes were approved, and might have been to force tests to pass (but I did not verify this).

Hence, I also updated the tests for the JUnit formatter so that they should run correctly on both Windows and *Nix machines by passing in an OS relevant suppliedFilePath to the test, and verifying with an OS relevant expectedClassName.

Is there anything you'd like reviewers to focus on?
Test sanity.

[kaicataldo]

Generally, I think this looks good. One question I have (and I'm not sure of the answer): Do we want to rely on our CI that runs our tests in multiple OS's to exercise this code, or should we be mocking process.platform in these tests to ensure these code paths are always hit?

[thewalla07]

Generally, I think this looks good. One question I have (and I'm not sure of the answer): Do we want to rely on our CI that runs our tests in multiple OS's to exercise this code, or should we be mocking process.platform in these tests to ensure these code paths are always hit?

I did some investigation on this and it seems less feasible to test this way, although I agree this would have been nicer. If we mock process.platform we need to be guaranteed that this is done before the node module path is loaded, otherwise we have issues because path does not dynamically check which platform we are on (and this makes sense, it shouldn't). Even if we can satisfy this guarantee, we then cannot switch back to another platform in the same test. We could override many functions in this module to get the desired behavior but I think this is overkill for this test scenario.

[kaicataldo]

Understood - thanks for the detailed explanation!

[kaicataldo]

This LGTM, but I'm not marking as accepted yet because I haven't been able to verify the issue. Will try to do so later today!

[kaicataldo]

Sorry, my Windows machine is on the fritz. Will need to fix it tomorrow to be able to test this. If someone else from the team is able to verify this bug, please feel free to mark as accepted.

[kaicataldo]

Thanks for contributing!