Of course, I think adding a simple html font tag / color tag to the test assertion text would do the job, but on the other hand, as it is logged, the plain text would be echoed on syslog as well. Which would on the other hand make it unreadable, or hardly readable.
So what we need to know is how nosetests / nosexunit processes the test result.
A quick nosetests --help shows us that nosetests features the following logging facilities (see under the -l / --debug switch):
- nose
- nose.importer
- nose.inspector
- nose.plugins
- nose.result
- nose.selector
Also, we know that the result of the test gets echoed to Syslog by our homegrown syslog plugin (which I fixed some posts ago). This happens thanks to the implementation of the formatFailure function, which overrides standard behaviour and formats the output by fetching the cause from the last exception (remember, assertion failures raise exceptions!).
A quick test on our Cruisecontrol host shows that the test's text results (which are merged by the Cruisecontrol agent at the end of the build cycle in the Cruisecontrl log test pages) are displayed as plain text. That is, HTML commands are uninterpreted. How comes?
The answer is simple : the text that is outputted by nosetests is interpreted by nosexunit as plain text, that is "<" and ">" signs are not interpreted as xml tags but as simple characters. Thus, when they get merged into the Cruisecontrol presentation panel through the XSLT transformations, those signs are converted in the & lt; and & gt; placeholders. That is, the "<" and ">" are still interpreted as plain text.
Specifically, this is the result of a merged nosexunit output (message is cutted down due to size constraints) :
<![CDATA[The test button <p style="color:red">'button 4'</p> has not .....;]]>
So it is actually merged as CDATA (obviously). The whole can be arranged with a small change in the XSLT transformation docs : check the \cruisecontrol\webapps\cruisecontrol\xslt folder, it contains all of the XSLT transformation schemes.
The one you are looking for is the errors.xsl. But first open the buildresults.xsl, and make sure that the entry which includes the errors.xsl is uncommented. You can tell so if by navigating to a build's log (by navigating on the project's name link) the Errors / Warnings section is displayed on the right part of the screen.
In the errors.xsl file you have to look for the match="message[@priority='warn']" pattern, and add the disable-output-escaping="yes" flag to the value-of instruction.
No comments:
Post a Comment