Repository navigation
junit: support ReportEntry - #1682
Conversation
| for _, entry := range spec.ReportEntries { | ||
| properties.Properties = append(properties.Properties, JUnitProperty{ | ||
| Name: entry.Name, | ||
| Value: entry.StringRepresentation(), |
There was a problem hiding this comment.
There's one potential issue: this will prefer the colored string if available, which is less suitable here than plain string. Is this worth addressing? Would imply changing StringRepresentation.
Or use a JSON dump as string after all?
There was a problem hiding this comment.
My instinct is to go with the JSON dump as the string as that enables structured objects to flow into the reports more naturally and it would align with what the Ginkgo JSON report does. If you want a non-colored string though then I'dd add a new entry.NoColorStringRepresentation()
There was a problem hiding this comment.
Okay, let's go with JSON then. I need to check how to get to that, though - if I remember correctly, it needs a new method.
There was a problem hiding this comment.
json.Marshal(entry.GetRawValue()) works without any new helper method.
There was a problem hiding this comment.
yep that's right. it mirrors ReportEntryValue.MarshalJSON()
|
hey @pohly this LGTM - i replied to your comment. feel free to take it in whatever direction you'd like. just let me know when you're happy with it and i'll pull it in and cut a release. |
Some JUnit tools support a "properties" element at the "testcase" level. This can be used to stored the ReportEntries attached to a spec. The string representation was chosen because the JUnit format seems to imply that this meant to be human-readable.
23fa08b to
3dad23b
Compare
Some JUnit tools support a "properties" element at the "testcase" level. This can be used to stored the ReportEntries attached to a spec. The string representation was chosen because the JUnit format seems to imply that this meant to be human-readable.