Harness

Harness makes use of several type of external files referenced from main test plan for different purposes like expected screen contents, http request body and expected response, file comparison sources and different types of configuration xml files.
The goal of this task is to allow specifying character encoding of the files to better support multi-platform usage.

I was looking at this too and came to the same conclusion of using InputStreamReader, but a question, why use an XML attribute for the encoding? The terminal encoding should be the same as the as the file encoding, and given that you would need for each CHECK-SCREEN-BUFFER to write the encoding attribute for each element, can't we directly use the encoding set from the CLI (Harness.getTerminalEncoding) through the -encoding parameter?

Șerban Bursuc wrote:

I was looking at this too and came to the same conclusion of using InputStreamReader, but a question, why use an XML attribute for the encoding? The terminal encoding should be the same as the as the file encoding, and given that you would need for each CHECK-SCREEN-BUFFER to write the encoding attribute for each element, can't we directly use the encoding set from the CLI (Harness.getTerminalEncoding) through the -encoding parameter?

I guess that assumption is not correct. Terminal encoding could be different than file encoding. You can have test screens captured using ISO8859 encoding, but terminal can use UTF8 encoding - I guess for that case you need an option to specify the encoding of file for plain text files.

Tomasz Domin wrote:

Șerban Bursuc wrote:

I was looking at this too and came to the same conclusion of using InputStreamReader, but a question, why use an XML attribute for the encoding? The terminal encoding should be the same as the as the file encoding, and given that you would need for each CHECK-SCREEN-BUFFER to write the encoding attribute for each element, can't we directly use the encoding set from the CLI (Harness.getTerminalEncoding) through the -encoding parameter?

I guess that assumption is not correct. Terminal encoding could be different than file encoding. You can have test screens captured using ISO8859 encoding, but terminal can use UTF8 encoding - I guess for that case you need an option to specify the encoding of file for plain text files.

For ChUI tests both the terminal and the plain text files need at least UTF-8 encoding, maybe this should be enforced. I think all screens that contain widgets use dashes as drawing primitives (─ or ┐), which are not supported in ISO8859-1 for example. So maybe the optimal decision would be to keep the flexibility of your patch, and add another CLI parameter for ChUI tests specifically to enforce an encoding for both terminal and screen files. This way we would avoid writing config attributes for each screen buffer check.

What do you think, Greg?

I do think it is possible that the file encoding could be different than the terminal encoding. An example of this is when screen captures are done on a legacy system that uses one codepage and then the system under test runs with a completely different terminal codepage.

I agree that we would want the ability to set the file encoding "globally" for the harness (the way we do with the terminal encoding). But I also see the need to allow specific files to have overrides in the XML elements of a test. This would be used for cases where someone adds some new screens using a newer system and those files differ from the global setting.

I think all screens that contain widgets use dashes as drawing primitives (─ or ┐), which are not supported in ISO8859-1 for example.

I don't think this is correct. In fact, the ChUI regression test suite that we use has characters that very likely are from 8859-1. Those drawing characters do work in that codepage, because it is the original codepage of the legacy system in that example.

Greg Shah wrote:

I do think it is possible that the file encoding could be different than the terminal encoding. An example of this is when screen captures are done on a legacy system that uses one codepage and then the system under test runs with a completely different terminal codepage.

I agree that we would want the ability to set the file encoding "globally" for the harness (the way we do with the terminal encoding). But I also see the need to allow specific files to have overrides in the XML elements of a test. This would be used for cases where someone adds some new screens using a newer system and those files differ from the global setting.

I think all screens that contain widgets use dashes as drawing primitives (─ or ┐), which are not supported in ISO8859-1 for example.

I don't think this is correct. In fact, the ChUI regression test suite that we use has characters that very likely are from 8859-1. Those drawing characters do work in that codepage, because it is the original codepage of the legacy system in that example.

The screen files we use for our ChUI tests are encoded in UTF-8 and since we are running them on a Linux environment FileReader also uses the UTF-8 charset. As far as I can see, those characters are UTF exclusive, for example https://www.compart.com/en/unicode/U+2510 and www.compart.com/en/unicode/U+2500.

The output that is used in the test screens is not from an OE environment, they were written manually, the baseline I mean. AFAIK there is no option in OE to copy the screen buffer to plain text, this is a FWD only feature for the chui_native GUI driver, and we mapped drawing primitives using UTF characters, this is why Harness works by matching text files. Correct me if I understood this incorrectly.

AFAIK there is no option in OE to copy the screen buffer to plain text, this is a FWD only feature for the chui_native GUI driver, and we mapped drawing primitives using UTF characters, this is why Harness works by matching text files.

Most of the baseline screens where not captured in the FWD ChUI driver, but in the original OE system using some terminal emulator like Putty. The text was just copied from the screen in those cases but since these were VT220 or VT320 terminals, the text was definitely NOT unicode. Perhaps we saved them into UTF-8 files (and thus translated the characters)?

Greg Shah wrote:

AFAIK there is no option in OE to copy the screen buffer to plain text, this is a FWD only feature for the chui_native GUI driver, and we mapped drawing primitives using UTF characters, this is why Harness works by matching text files.

Most of the baseline screens where not captured in the FWD ChUI driver, but in the original OE system using some terminal emulator like Putty. The text was just copied from the screen in those cases but since these were VT220 or VT320 terminals, the text was definitely NOT unicode. Perhaps we saved them into UTF-8 files (and thus translated the characters)?

Then I am really curious as to what characters were used for the Putty output, since the drawing characters I saw used for Harness are UTF exclusive. Putty also supports UTF-8 and above. I understand that VT220 and VT320 don't support unicode, but if Putty supports UTF-8 then the screen buffers can still include those special characters in the screen buffer text output. I guess I will have to test this to be fully convinced, otherwise I don't see how the screen buffer is stored in a plain text file and those line primitives are stored.

Tomasz Domin wrote:

In meantime I've created task branch harness_repo/harness/active/9922a/ and started to work. Attached 9922a.diff patch to make screen captures encoding work. Sorry.

Tomasz, is this the full patch? ATTR_ENCODING is not defined. Are there any other changes?

Șerban Bursuc wrote:

Tomasz Domin wrote:

In meantime I've created task branch harness_repo/harness/active/9922a/ and started to work. Attached 9922a.diff patch to make screen captures encoding work. Sorry.

Tomasz, is this the full patch? ATTR_ENCODING is not defined. Are there any other changes?

Are you on harness trunk revision 36 or later ?

Tomasz Domin wrote:

Șerban Bursuc wrote:

Tomasz Domin wrote:

In meantime I've created task branch harness_repo/harness/active/9922a/ and started to work. Attached 9922a.diff patch to make screen captures encoding work. Sorry.

Tomasz, is this the full patch? ATTR_ENCODING is not defined. Are there any other changes?

Are you on harness trunk revision 36 or later ?

I was using rev 35 indeed. Updated it to the latest revision and the patch works well. Tested with a small test and after adding an encoding attribute the tests pass, the file is being read with the specified charset.

The patch from #9922-4 is good, it has been tested.

Tomasz, can you add a history entry to the changes in 9922a? After that the branch should probably be merged, unless another review is needed.

Shouldn't the close of the BufferedReader be in a finally block?

What testing is needed?

Tomasz, are all changes committed for this task?

Constantin Asofiei wrote:

Tomasz, are all changes committed for this task?

Now they are - committed 9922c.diff

modified src/com/goldencode/harness/test/TestFactory.java
Committed revision 39

Greg Shah wrote:

Code Review Task Branch 9922a Revision 39

The changes are good. Have they been tested?

I've tested the changes while working with regression testing, also Serban did some testing - see #9922-16