There is no test target at all today.
Where the value is
Be honest about the shape of this app: most of it is AppKit wiring, which unit tests will not reach.
The parts worth covering are the few places with actual decisions in them:
- Which point the pointer should move to, given a set of screens. This is the logic that has
already been wrong once, and it involves two coordinate systems that agree only in the common
case — exactly the kind of thing a test pins down better than a comment.
- Whether an event should be acted on, given the current preferences. This is where the
shortcut/system-event coupling bug lived.
- Preference defaults and round-tripping.
Notes
The centring logic is currently entangled with NSScreen and CGWarpMouseCursorPosition, so some
extraction is needed before it can be tested — pulling the "given these screen frames, return this
point" calculation out as a pure function is the obvious seam, and it is worth doing on its own
merits.
Adding a test target also means a new scheme, which the build script and CI both need to know about.
There is no test target at all today.
Where the value is
Be honest about the shape of this app: most of it is AppKit wiring, which unit tests will not reach.
The parts worth covering are the few places with actual decisions in them:
already been wrong once, and it involves two coordinate systems that agree only in the common
case — exactly the kind of thing a test pins down better than a comment.
shortcut/system-event coupling bug lived.
Notes
The centring logic is currently entangled with
NSScreenandCGWarpMouseCursorPosition, so someextraction is needed before it can be tested — pulling the "given these screen frames, return this
point" calculation out as a pure function is the obvious seam, and it is worth doing on its own
merits.
Adding a test target also means a new scheme, which the build script and CI both need to know about.