Skip to content

test_runner: remove failure attribute in junit_report testcase element - #59685

Open
devholic22 wants to merge 1 commit into
nodejs:mainfrom
devholic22:fix-junit-element
Open

test_runner: remove failure attribute in junit_report testcase element#59685
devholic22 wants to merge 1 commit into
nodejs:mainfrom
devholic22:fix-junit-element

Conversation

@devholic22

@devholic22 devholic22 commented Aug 30, 2025

Copy link
Copy Markdown

Fixes: #59593

This PR aligns the Node.js test runner’s JUnit XML output with the official JUnit specification by removing the non-standard failure attribute from elements and replacing it with a proper nested tag.

Changes

• Remove non-compliant failure attribute from elements
• Update snapshot tests accordingly

Background

The JUnit XML specification mandates that failure details must be represented via a nested (child) <failure> element inside a <testcase>, rather than as an attribute.

스크린샷 2025-08-30 오후 4 39 27

However, the Node.js test runner previously:
• Incorrectly embedded the failure message as a failure="..." attribute on , which is not spec-compliant
• This caused compatibility issues with tools like GitLab, Jenkins, or any CI/CD pipeline that parses JUnit reports strictly

Before:

<testcase name="testName" time="0.002234" classname="test" failure="The value must be 01 !== 0">
  <failure type="testCodeFailure" message="The value must be 01 !== 0">

After:

<testcase name="testName" time="0.002234" classname="test">
    <failure type="testCodeFailure" message="The value must be 01 !== 0">

Testing

스크린샷 2025-08-30 오후 4 06 57
  • All existing tests pass

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/test_runner

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. test_runner Issues and PRs related to the test runner subsystem. labels Aug 30, 2025
children: [inspectWithNoCustomRetry(error, inspectOptions)],
});
currentTest.failures = 1;
currentTest.attrs.failure = error?.message ?? '';

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the change the good, I wonder if we have to treat this as potentially breaking? @nodejs/test_runner @nodejs/tsc any thoughts? I'm fine landing as a semver-patch but want to be sure.

@MoLow MoLow left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. also not sure rgarding semver-major vs patch

@lpinca lpinca added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 1, 2025
@github-actions github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 1, 2025
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@codecov

codecov Bot commented Sep 1, 2025

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.13%. Comparing base (cc60845) to head (7cca5c1).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #59685   +/-   ##
=======================================
  Coverage   90.13%   90.13%           
=======================================
  Files         752      752           
  Lines      251820   251819    -1     
  Branches    47352    47353    +1     
=======================================
+ Hits       226974   226983    +9     
- Misses      16158    16174   +16     
+ Partials     8688     8662   -26     
Files with missing lines Coverage Δ
lib/internal/test_runner/reporter/junit.js 95.32% <ø> (+0.55%) ⬆️

... and 47 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@CuriousStork

Copy link
Copy Markdown

Hello @atlowChemi

#59593 is auto-closed because #60274 has been merged, thank you.

Probably this PR also needs a ping, or should we reopen the issue #59593?

@mcollina

Copy link
Copy Markdown
Member

The commit message here needs an amend

@CuriousStork

Copy link
Copy Markdown

Hello @devholic22

Are you planning to amend the commit message? Thank you.

@github-actions

Copy link
Copy Markdown
Contributor

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

@github-actions github-actions Bot added the stale label Jul 28, 2026
@CuriousStork

Copy link
Copy Markdown

@jasnell @mcollina @MoLow Hi! Since the original author has been inactive for a while, could one of the collaborators please amend the commit message and land this on their behalf?

This is a useful fix for #59593 to keep the JUnit output spec-compliant, and it already has 5 approvals. Thanks!

This commit aligns the Node.js test runner’s JUnit XML output with the
official JUnit specification by removing the non-standard failure
attribute from elements and replacing it with a proper nested tag.
@aduh95
aduh95 force-pushed the fix-junit-element branch from 4a5ccc4 to 7cca5c1 Compare August 17, 2026 12:44
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@aduh95 aduh95 added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. and removed stale labels Aug 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author ready PRs that have at least one approval, no pending requests for changes, and a CI started. needs-ci PRs that need a full CI run. test_runner Issues and PRs related to the test runner subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JUnit XML failure element and attribute are incorrect when using node:assert

10 participants