JUnit reporter: distinguish thrown errors from assertion failures

[aviavi16]

🚀 Feature Request

Distinguish between assertion failures and thrown/runtime errors
in the JUnit reporter output.

Currently, thrown errors (e.g. throw new Error('Boom')) are serialized
as <failure>, making them indistinguishable from assertion failures.

Evidence

Current behavior (before):
junit-before.xml

Proposed behavior (after):
junit-after.xml

Compatibility

This proposal does not change default JUnit output.
Existing consumers that rely on <failure> will not be affected.

Only users who explicitly enable the flag will get:

• <error> elements
• errors++ counters

Why this matters

CI systems such as Jenkins, Xray and TestRail
treat <failure> and <error> differently.

Currently, a thrown runtime exception:

• increments failures
• produces no <error> node

This makes it impossible to distinguish assertion failures
from infrastructure / test crashes.

Example

Example:

Given a test that throws a runtime error:

test('example', () => {
throw new Error('Boom');
});

Current JUnit output:

• The test is reported as <failure>
• errors="0" and failures="1"

Proposed behavior:

• The test is reported as <error>
• errors="1" and failures="0"

Assertion failures (expect(...)) would remain reported as <failure>.

Motivation

JUnit distinguishes between assertion failures and runtime errors,
and many CI and test-reporting systems rely on this distinction
(e.g. Jenkins, Xray, TestRail).

When all failures are serialized as <failure>, these systems cannot
correctly classify test outcomes, making it harder to reason about
test health and failure modes.

Aligning Playwright’s JUnit reporter with standard JUnit semantics
would improve interoperability without changing assertion behavior.