Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change JUnit terraform test output to include test failure details inside <failure> elements, use the error message as the message attribute #36316

Merged
merged 9 commits into from
Jan 22, 2025

Conversation

SarahFrench
Copy link
Member

@SarahFrench SarahFrench commented Jan 14, 2025

This PR

Related:

  • Update docs for -junit-xml flag

Target Release

1.11.x

CHANGELOG entry

  • This change is user-facing and I added a changelog entry.
  • This change is not user-facing.

This change relates to a feature that isn't released yet

@SarahFrench
Copy link
Member Author

SarahFrench commented Jan 15, 2025

Questions for the reviewer:

  • Is there any risk of the message spanning multiple lines? This was the blocker mentioned in the Discuss thread linked in the description
  • Opinions re: the element's body content? This has been discussed

@SarahFrench SarahFrench marked this pull request as ready for review January 15, 2025 21:37
@SarahFrench SarahFrench requested a review from a team as a code owner January 15, 2025 21:37
@@ -1,17 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?><testsuites>
<testsuite name="main.tftest.hcl" tests="2" skipped="0" failures="1" errors="0">
<testcase name="failing_assertion" classname="main.tftest.hcl" time="TIME_REDACTED" timestamp="TIMESTAMP_REDACTED">
<failure message="Test run failed"></failure>
<failure message="local variable &#39;number&#39; has a value greater than zero, so assertion 2 will fail"><![CDATA[Test failed on assertion 2 of 3]]></failure>
Copy link
Member Author

Choose a reason for hiding this comment

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

These strings will contain HTML character references, depending on the message. I assume the tools using the XML will parse this fine.

@SarahFrench SarahFrench changed the title Change JUnit terraform test output to include test failure details in <failure> elements Change JUnit terraform test output to include test failure details inside <failure> elements, use the error message as the message attribute Jan 16, 2025
internal/command/junit/junit.go Outdated Show resolved Hide resolved
internal/command/junit/junit.go Outdated Show resolved Hide resolved
internal/command/junit/junit.go Outdated Show resolved Hide resolved
@SarahFrench SarahFrench force-pushed the junit-add-failure-details branch from 338114b to 080505c Compare January 21, 2025 12:08
@SarahFrench SarahFrench added the no-changelog-needed Add this to your PR if the change does not require a changelog entry label Jan 21, 2025
Comment on lines +218 to +219
// From internal/backend/remote-state/s3/testing_test.go
// diagnosticComparer is a Comparer function for use with cmp.Diff to compare two tfdiags.Diagnostic values
Copy link
Member Author

Choose a reason for hiding this comment

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

Should/could this be moved into the tfdiags package? Or are there other ways that diagnostics are compared in the code base that are a better option?

Copy link
Member

Choose a reason for hiding this comment

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

I think moving it into tfdiags is a good idea!

We could follow the pattern of ctydebug - https://github.com/zclconf/go-cty-debug/blob/0d6042c539401a57fc0cca85ded2861d4a5173c4/ctydebug/cmp.go#L19-L42 I don't mean the implementation necessarily but more the fact that it exports a cmp.Option variable which can be directly used as an argument in cmp.Diff.

Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

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

LGTM! Feel free to merge and leave the in-line comments for a separate PR at some point later.

Comment on lines +218 to +219
// From internal/backend/remote-state/s3/testing_test.go
// diagnosticComparer is a Comparer function for use with cmp.Diff to compare two tfdiags.Diagnostic values
Copy link
Member

Choose a reason for hiding this comment

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

I think moving it into tfdiags is a good idea!

We could follow the pattern of ctydebug - https://github.com/zclconf/go-cty-debug/blob/0d6042c539401a57fc0cca85ded2861d4a5173c4/ctydebug/cmp.go#L19-L42 I don't mean the implementation necessarily but more the fact that it exports a cmp.Option variable which can be directly used as an argument in cmp.Diff.

@@ -67,6 +70,65 @@ func Test_TestJUnitXMLFile_save(t *testing.T) {
}
}

func Test_getWarnings(t *testing.T) {

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change

Comment on lines +358 to +369
func getWarnings(diags tfdiags.Diagnostics) tfdiags.Diagnostics {
// Collect warnings
warnDiags := tfdiags.Diagnostics{}
if diags.HasWarnings() {
for _, d := range diags {
if d.Severity() == tfdiags.Warning {
warnDiags = warnDiags.Append(d)
}
}
}
return warnDiags
}
Copy link
Member

Choose a reason for hiding this comment

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

Nitpick - AFAICT the code here would work just as well without HasWarnings() - it would return empty slice as nothing would be appended.

On a separate note I am somewhat surprised we don't have Warnings() method yet on tfdiags.Diagnostics - so I think it may be another candidate for logic to extract there and just call from here but feel free to leave this for another PR if you like.

@SarahFrench SarahFrench added the 1.11-backport If you add this label to a PR before merging, backport-assistant will open a new PR once merged label Jan 22, 2025
@SarahFrench
Copy link
Member Author

SarahFrench commented Jan 22, 2025

Thanks! I'll address those in follow-up PRs like you suggested; as long as this PR's changes are in 1.11 then any refactors can be kept on main/in 1.12. As well as those comments I'll address this feedback about making test assertion failure diags more easily identify-able.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.11-backport If you add this label to a PR before merging, backport-assistant will open a new PR once merged no-changelog-needed Add this to your PR if the change does not require a changelog entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants