My SWTBot UI tests recently started failing on GitHub Actions macOS runners.
The application under test is an Eclipse-based application, so at first I expected the failure to be caused by some SWTBot timing issue, focus issue, or maybe a regression in my own code.
However, the screenshot captured by the failed test showed something completely unrelated to my application:
That is not Eclipse. That is macOS Setup Assistant.
More specifically, it was the macOS Analytics screen asking whether to share analytics data with Apple and app developers. Since SWTBot drives the UI that currently has focus, this dialog was stealing focus from Eclipse and making the test interact with the wrong window.
The first workaround
My first attempt was to dismiss the Analytics dialog before starting the SWTBot tests:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
- name: Dismiss macOS Analytics setup dialog if: runner.os == 'macOS' shell: bash run: | for i in {1..30}; do if pgrep -x "Setup Assistant" >/dev/null; then echo "Found macOS Setup Assistant; trying to dismiss it" osascript <<'APPLESCRIPT' || true tell application "System Events" if exists process "Setup Assistant" then tell process "Setup Assistant" set frontmost to true delay 0.2 try click button "Continue" of window 1 on error key code 36 end try end tell end if end tell APPLESCRIPT sleep 2 pgrep -x "Setup Assistant" >/dev/null || exit 0 fi sleep 1 done |
This looked reasonable, but then the failure changed.
The new screenshot showed another Setup Assistant page:
This time it was the “Welcome to Mac” screen.
So the script was managing to click something, but Setup Assistant was still not completely gone. SWTBot was still losing focus before the actual Eclipse application could be tested.
The final workaround
The most robust fix was to avoid heredocs entirely and pass the AppleScript using repeated osascript -e arguments.
Here is the workflow step I now use:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
- name: Remove macOS Setup Assistant if: runner.os == 'macOS' shell: bash run: | for i in {1..10}; do if ! pgrep -x "Setup Assistant" >/dev/null; then echo "Setup Assistant is not running" exit 0 fi echo "Setup Assistant is running; trying to dismiss it" osascript \ -e 'tell application "System Events"' \ -e 'if exists process "Setup Assistant" then' \ -e 'tell process "Setup Assistant"' \ -e 'set frontmost to true' \ -e 'delay 0.2' \ -e 'try' \ -e 'perform action "AXPress" of button "Continue" of window 1' \ -e 'end try' \ -e 'delay 0.5' \ -e 'end tell' \ -e 'key code 36' \ -e 'end if' \ -e 'end tell' >/dev/null 2>&1 || true sleep 2 done echo "Setup Assistant did not go away; killing it" pkill -9 -x "Setup Assistant" || true sleep 2 if pgrep -x "Setup Assistant" >/dev/null; then echo "::error::Setup Assistant is still running" exit 1 fi |
This does three things:
- It checks whether
Setup Assistantis running. - It tries to press the visible Continue button.
- If Setup Assistant still refuses to disappear, it kills the process before the UI tests start.
After adding this step before launching Eclipse, the SWTBot tests started passing again.
Why this matters for SWTBot
SWTBot tests are particularly sensitive to focus problems.
They do not just test some isolated backend logic. They drive a real UI. If another native macOS window appears in front of the Eclipse workbench, the test can fail in confusing ways:
|
1 2 3 4 |
WidgetNotFoundException TimeoutException Could not find shell Could not find button |
The actual problem may have nothing to do with SWTBot or Eclipse. The test may simply be interacting with the wrong application.
That is why screenshots from failed UI tests are invaluable. Without the screenshot, I would probably have spent a lot more time debugging Eclipse, SWTBot, or my own application.