Repository: terminal
Issue: Unit test framework for terminal emulation
Labels: Issue-Feature,Area-VT,Product-Terminal

# Summary of the new feature/enhancement

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

Currently, terminal emulation for unix is extremely incomplete.
 - The parser fails in many circumstances and can't cope with what would be considered backwards references in a regular expression engine. It is missing support for many different modes of operation...
 - The terminal escape sequence interpreter is minimal. It's as approximately the same state that my terminal emulator [VtNetCore.UWP](https://github.com/darrenstarr/VtNetCore.UWP) was on the second or third day of development. It has barely a minimal implementation required to run a few sample cases. Things like midnight commander barely function at all (though I'm REALLY impressed by how much does function). vttest more or less considers Microsoft Terminal to be more or less unusable... look at [basic terminal comparison on windows](https://medium.com/@ITGuyGoneBad/vttest-on-different-terminals-4235d4d7aee6)
 - Unit tests for the parser and the command sequence interpreter are minimal at best, incorrect in some cases and are very coarse grained.

I don't believe that the current state of the terminal emulator's unit testing framework is suitable for permitting clear pull requests or filing clear issues with test cases.

Anyone who creates a terminal which should test for correctness needs to have a proper testing framework and it would be impossible for any of us to make a terminal work without this.

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->

I recommend writing a unit test framework that is part of the CI pipeline that supports describing and writing unit tests in the following fashion

- Name of test
- Input data
- Compliance level (minimum viable product/ECMA-48/xterm/academic)
- Expected cursor state?
- Expected window characteristics?
- Expected window text and attributes?
- Query text characteristics (character width, character height, etc...)?
- Query window as pixels?
- Query window as text?
- Query current buffer?
- Query mouse pointer?
- Query mouse position?
- Query mouse colors?
- Query protected areas?
- Query current character set?
- Query state of sequence parser?
- Query state of sequence buffer?

I recommend supporting a "function as a service" implementation that would allow describing the test as a JSON file and a Javascript or Typescript file for the test itself. 

I intend to work towards this goal with my VtNetCore engine as well. I have about 200 unit tests at this time and have planned another 1000+ for the additional features I currently support. If we do this together, we can standardize a virtual terminal test suite.

If you look at VtNetCore, you can see how to start a legitimate test suite (in this case using XUnit) for compliance. I highly recommend also looking at [libvterm](https://github.com/neovim/libvterm), they have done an excellent job of setting an example for all of us. But they have some very serious limitations that can't be solved by writing such a simple query language. We should use something more robust.

If Microsoft is going to make a real attempt at a real terminal emulator and they're going to claim compliance, you absolutely must provide a better means for providing tests. At this time, the test suite (see OutputEngineTest) is just too complex and it's not possible for people like me, or like Thomas Dickey or anyone else to provide a meaningful bug report.