Skip to content

fix: treat '<error>' testcases as failed instead of passed - #774

Open
antonkri wants to merge 1 commit into
mainfrom
fix/xml-parser-error-element
Open

fix: treat '<error>' testcases as failed instead of passed#774
antonkri wants to merge 1 commit into
mainfrom
fix/xml-parser-error-element

Conversation

@antonkri

Copy link
Copy Markdown
Contributor

parse_testcase_result only inspected the <failure> and <skipped> child elements of a <testcase>:

if skipped is None and failed is None:
    return "passed", ""

JUnit XML also uses <error> for testcases that did not complete, e.g. an uncaught exception in Python's unittest or a crashing binary. Such a testcase has neither <failure> nor <skipped>, so it fell into the branch above and was reported as passed.

That is the worst possible failure mode for a verification report: a broken test silently shows up as a green (passed) badge next to the requirement it is supposed to verify.

Handle <error> explicitly and map it to failed, using the element's message attribute as the result text. An existing <failure> still takes precedence, so the reported message stays the assertion message when both elements are present.

📌 Description

🚨 Impact Analysis

  • This change does not violate any tool requirements and is covered by existing tool requirements
  • This change does not violate any design decisions
  • Otherwise I have created a ticket for new tool qualification

✅ Checklist

  • Added/updated documentation for new or changed features
  • Added/updated tests to cover the changes
  • Followed project coding standards and guidelines

`parse_testcase_result` only inspected the `<failure>` and `<skipped>`
child elements of a `<testcase>`:

    if skipped is None and failed is None:
        return "passed", ""

JUnit XML also uses `<error>` for testcases that did not complete, e.g.
an uncaught exception in Python's `unittest` or a crashing binary. Such
a testcase has neither `<failure>` nor `<skipped>`, so it fell into the
branch above and was reported as `passed`.

That is the worst possible failure mode for a verification report: a
broken test silently shows up as a green `(passed)` badge next to the
requirement it is supposed to verify.

Handle `<error>` explicitly and map it to `failed`, using the element's
`message` attribute as the result text. An existing `<failure>` still
takes precedence, so the reported message stays the assertion message
when both elements are present.
@github-actions

Copy link
Copy Markdown
Contributor

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //src:license-check

Status: ⚠️ Needs Review

Click to expand output
[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: f3544429-ad4a-4551-a236-4881f85973f3
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: src
WARNING: Target pattern parsing failed.
ERROR: Skipping '//src:license-check': no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
ERROR: no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
INFO: Elapsed time: 5.404s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

@github-actions

Copy link
Copy Markdown
Contributor

Documentation preview for this pull request is available at:
pr-774: https://eclipse-score.github.io/docs-as-code/pr-774/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant