Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: nunit-plugin
-
Labels:
-
Environment:Jenkins ver. 2.89.4
NUnit Plugin
-
Similar Issues:
Description
Test results contain wrongly encoded characters when evaluating NUnit test results. Some characters are turned into question marks.
Specifically our test reports contain the following test case and similar ones:
<test-case name="Test.Namespace.TestSuite.SaveAlphaNumericals("Ö")" executed="True" result="Success" success="True" time="5.411" asserts="19"/>
(test name simplified and anonymized)
In the test report view of Jenkins this test case is displayed as:
The special characters are turned to ??.
This happens for all test cases containing special characters like Ä,Ö,Ü or °, so in the test result the cases can't be distinguished anymore.
Attachments
Activity
That may be what you prefer, but there are several people who use the plugin and want something different. So, I need to determine the best way to handle it.
I'm sorry, my last comment is totally wrong. Please forget it.
In order to handle invalid characters correctly, maybe the following should be done:
- Decode chars from utf-8 bytes.
- Replace invalid chars.
- Encode the chars to utf-8 bytes.
- Pass the utf-8 bytes to Transformers.
But I prefer treating broken xml files as build errors because the core problem is that something generates broken xml files.
As a CI manager, I want to detect such problems as soon as possible instead of hiding them, so that I can investigate and correct them.
One possible solution might be to make this behavior (replacing non-ascii bytes to ?) optional.
Regards,
Shin-ichi Morita
added a comment - I'm sorry, my last comment is totally wrong. Please forget it.
In order to handle invalid characters correctly, maybe the following should be done:
Decode chars from utf-8 bytes.
Replace invalid chars.
Encode the chars to utf-8 bytes.
Pass the utf-8 bytes to Transformers.
But I prefer treating broken xml files as build errors because the core problem is that something generates broken xml files.
As a CI manager, I want to detect such problems as soon as possible instead of hiding them, so that I can investigate and correct them.
One possible solution might be to make this behavior (replacing non-ascii bytes to ?) optional.
Regards,
I understand the difficulty.
As the second best solution, how about converting negative values to unsigned ints in isValid()?
input = input & 0xff;
It would work for me as long as the character encoding is utf-8.
Regards,
Shin-ichi Morita
added a comment - - edited I understand the difficulty.
As the second best solution, how about converting negative values to unsigned ints in isValid()?
input = input & 0xff;
It would work for me as long as the character encoding is utf-8.
Regards, The reason the invalid xml stream was added was for the case of broken xml files. The plugin used to just break completely, this was a way to continue parsing if possible. I agree it is not the best solution, but the upper xml parsers and so forth didn't handle the issues that were run into.
OK, I understand that
Let me backup our situation a little. We describe most of our test names, assertion messages in Japanese. So our job shows unreadable test results like the following:
It would be nice to have a way not to replace non-ascii bytes to ?.
Thank you.