You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue reported in microsoft/git#730 was
fixed, but due to missing tests for the issue a regression slipped in
within mere weeks.
Let's add an integration test that will (hopefully) prevent this issue
from regressing again.
This integration test is implement as an AutoHotKey script. It might
look unnatural to use a script language designed to implement global
keyboard shortcuts, but it is a quite powerful approach. While
there are miles between the ease of developing AutoHotKey scripts and
developing, say, Playwright tests, there is a decent integration into VS
Code (including single-step debugging), and AutoHotKey's own development
and community are quite vibrant and friendly.
I had looked at alternatives to AutoHotKey, such as WinAppDriver,
SikuliX, nut.js and AutoIt, in particular searching for a solution that
would have a powerful recording feature similar to Playwright, but did
not find any that is 1) mature, 2) well-maintained, 3) open source and
4) would be easy to integrate into a GitHub workflow. In the end,
AutoHotKey appeared my clearest preference.
So how is the test implemented? It lives in `ui-test/` and requires
AutoHotKey v2 as well as Windows Terminal (the Legacy Prompt would not
reproduce the problem). It then follows the reproducer I gave to the
Cygwin team:
1. initialize a Git repository
2. install a `pre-commit` hook
3. this hook shall spawn a non-Cygwin/MSYS2 process in the background
4. that background process shall print to the console after Git exits
5. open a Command Prompt in Windows Terminal
6. run `git commit`
7. wait until the background process is done printing
8. press the Cursor Up key
9. observe that the Command Prompt does not react (in the test, it
_does_ expect a reaction: the previous command in the command
history should be shown, i.e. `git commit`)
In my reproducer, I then also suggested to press the Enter key and to
observe that now the "More ?" prompt is shown, but no input is accepted,
until Ctrl+Z is pressed. Naturally, the test should not expect _that_
;-)
There were a couple of complications I needed to face when developing
this test:
- I did not find any easy macro recorder for AutoHotKey that I liked. It
would not have helped much, anyway, because intentions are hard to
record.
- Before I realized that there is excellent AutoHotKey support in VS
Code via the AutoHotKey++ and AutoHotKey Debug extensions, I struggled
quite a bit to get the syntax right.
- Windows Terminal does not use classical Win32 controls that AutoHotKey
knows well. In particular, there is no easy way to capture the text
that is shown in the Terminal. I tried the (pretty excellent!) [OCR
for AutoHotKey](https://github.com/Descolada/OCR), but it uses UWP OCR
which does not recognize constructs like "C:\Users\runneradmin>"
because it is not English (or any other human language). I ended up
with a pretty inelegant method of selecting the text via mouse
movements and then copying that into the clipboard. This stops
scrolling and I worked around that by emulating the mouse wheel
afterwards.
- Since Windows Terminal does not use classical Win32 controls, it is
relatively hard to get to the exact bounding box of the text, as there
is no convenient way to determine the size of the title bar or the
amount of padding around the text. I ended up hard-coding those
values, I'm not proud of that, but at least it works.
- Despite my expectations, `ExitApp` would not actually exit AutoHotKey
before the spawned process exits and/or the associated window is
closed.
Signed-off-by: Johannes Schindelin <[email protected]>
0 commit comments