Unreadable test result

[evis]

Test result from scalatest in buildbuddy is quite unreadable sometimes.

Screenshots

Test log: build_logs.txt

test.xml from buildbuddy: test.xml.zip

If some more info is needed, tell me please.

Here is a hint on how to fix it: buildbuddy-io/buildbuddy#6453 (comment)

The problematic part from the snippet that Son showed is this part:

<failure 
      message="Unexpected not mocked invocation getLatestResult(car_info {&amp;#010;  mark: &quot;

note that the message is quite verbose and contains entities like 
 etc.

I don't have a ton of experience with these XML files and hoping other folks can chime in if they have more experience with this, but from reading the XML schema documentation here I think that in normal usage, the message attribute (assert message) is intended for a short summary of the error (a few words), while the text content inside the <failure> tag should contain more details such as the stack trace. It appears that in the XML doc you provided, the same full error message is included in both the message attribute and the text of the tag.

A quick fix that I could think of is to patch rules_scala so that the message attribute will only include the first line of failure.message. That will give you a much more readable error with Junit XML and Bazel (and BuildBuddy).

I think it's from rules_scala with

rules_scala/scala/support/JUnitXmlReporter.scala

Lines 412 to 437 in e2fe29c

	//
	// Generates <failure> xml for TestFailed event, if specified Option
	// contains one.
	//
	private def failureXml(failureOption: Option[TestFailed]): xml.NodeSeq = {
	failureOption match {
	case None =>
	xml.NodeSeq.Empty
	case Some(failure) =>
	val (throwableType, throwableText) =
	failure.throwable match {
	case None => ("", "")
	case Some(throwable) =>
	val throwableType = "" + throwable.getClass
	val throwableText = getStackTrace(throwable)
	(throwableType, throwableText)
	}
	<failure message = { failure.message.replaceAll("\n", "&#010;") }
	type = { throwableType } >
	{ throwableText }
	</failure>
	}
	}

could you please open an issue on rules_scala to report this? I think rules_scala maintainers would have more context on how scalatest runner created these events, as well as best practices from other Scala build tools to replicate over.

[evis]

@liucijus could you take a look?

[liucijus]

@evis would you be willing to contribute and test such change?