Invalid XML structure in jUnit with constructor stack trace

[Erisiel]

Summary

Test command generates invalid XML structure for jUnit when one of the tests results in a exception that generates a stack trace that includes a constructor. The constructor will be listed as ClassName. in the failure message attribute which is not valid for XML.

Validation error:
The value of attribute "message" associated with an element type "failure" must not contain the '<' character.xml(LessthanInAttValue)

<testcase name="TestMethodName" classname="ClassName" time="1.12">
            <failure message="System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, ClassName: execution of BeforeInsert
caused by: jException: No Salesforce profile for ProfileX

Class.Class1.Method: line 20, column 1
Class.Class2.<init>: line 158, column 1
Class.Class3: line 528, column 1
Class.Class3: line 344, column 1
Class.Class4: line 23, column 1
Class.Class5.execute: line 105, column 1
Trigger.Class6: line 3, column 1: []"><![CDATA[Class.ClassName.TestMethodName: line 20, column 1]]></failure>
        </testcase>

Steps To Reproduce:

1. Make a test class that tests code that somewhere hits a constructor and hits an exception after.
2. run sfdx force:apex:test:report -i [testid] -u [OrgAlias] -r junit -d [locationFile]
3. View Junit

Expected result

Perhaps it would make more sense to have the stack trace as part of the value of the failure element in the CDATA block and the message be more only of a description.

Actual result

Stack Trace in Message attribute of the failure element. Causing invalid XML structure

Additional information

Mac BigSur 11.4
sfdx-cli/7.110.0 darwin-x64 node-v14.17.3

Also Bitbucket pipelines in SalesforceDX docker container https://hub.docker.com/r/salesforce/salesforcedx/ tag:latest-slim

[Erisiel]

Actually digging through the cli code i found where the data is coming from. Seems the cli does exactly what is intended. The issue seems to come from how the data is structured in the actual ApexTestResult.

Apparently a DML exception triggered by another (Custom) exception returns the stack trace of that custom exception in it's message field. As a "caused by"

[jverelst]

@Erisiel I ran into the same issue, but with another character (the double-quote) which was also not escaped correctly in the junit XML generation. I was able to fix it myself locally, so I've just created a PR that should solve both our problems:

#279