Hi On 2026-10-02 16:19, Larry Garfield wrote:
My main concern is being able to mock the terminal in order to effectively test code that uses the terminal, without putting a proprietary thin wrapper around it (which largely defeats the purpose of having a good API in core).
It is not clear to me what you mean by “proprietary” here. As I had mentioned in my email, the RFC’s own PR is tested against processes spawned using `proc_open()` with `pty` descriptors. The tests are naturally BSD-licensed, just like PHP itself is (since PHP 8.6).
In your test you would create a process that emits scripted output (possibly in response to some input), just like you would in the “mocked interface implementation” and then pass the PTY input/output streams to whatever you want to test, which will then call `(System)Terminal::fromStreams()` using them as parameters. The logic under test reads inputs from the Terminal instance and writes output using `fwrite()`. The subprocess will also enable you to properly model concurrency, delay and timing in IO processing. Terminal interactions in the real world are not synchronous either: The terminal logic relies on timing to distinguish escape sequences from individual characters (that's what the `$sequenceTimeout` is for) and the user might already provide additional input while your application is still busy rendering output and not yet expecting additional data.
Interfaces are the standard way of doing that. If you have a suggestion for a better way, I'm happy to see it.
My email included 5 arguments as to why an interface is the wrong design here. Do you plan to engage with those?
Best regards Tim Düsterhus
