IIRC... It was either Ruby or Ceedling's fault that non-ASCII chars would break a test. It's dumb, but I remember slamming my head on the table at this. This was fixed in Ceedling (yay), it breaks this test adapter quietly (boo).
-
If the test contains non-ascii chars, Ceedling CLI runs it fine and generates a report.xml in the build folder. Maybe this is a region or locale thing correctly handled now.
-
However, if running through the test adapter, either for locale reasons or other, the report.xml file is not generated. Invalid byte sequence on the non-ascii chars, even if they are in comments. The reported errors were only about how report.xml was not found.
Fwiw, it is apparently also a problem with the old version of the test adapter. The fix should be that it both handles all text and if any error fails to generate the report.xml file that error is presented to the output instead of just informing the file was not found.
IIRC... It was either Ruby or Ceedling's fault that non-ASCII chars would break a test. It's dumb, but I remember slamming my head on the table at this. This was fixed in Ceedling (yay), it breaks this test adapter quietly (boo).
If the test contains non-ascii chars, Ceedling CLI runs it fine and generates a report.xml in the build folder. Maybe this is a region or locale thing correctly handled now.
However, if running through the test adapter, either for locale reasons or other, the report.xml file is not generated. Invalid byte sequence on the non-ascii chars, even if they are in comments. The reported errors were only about how report.xml was not found.
Fwiw, it is apparently also a problem with the old version of the test adapter. The fix should be that it both handles all text and if any error fails to generate the report.xml file that error is presented to the output instead of just informing the file was not found.