feat(ci): add explicit Safari tap/type/scroll smoke scenarios (#501)#583
Merged
feat(ci): add explicit Safari tap/type/scroll smoke scenarios (#501)#583
Conversation
13 tasks
Epic #484's acceptance criterion for the Safari smoke job is "Safari 자동화 — 임의 페이지 탭/입력/스크롤 통과", but the existing `safari-smoke` job only runs `opensafari audit` (a one-shot QA scan). The explicit interaction scenarios were never exercised, so the corresponding checkbox on #501 could not be flipped honestly. Changes: - Add `tests/integration/safari-smoke.live.test.ts` covering tap (button click), type (input dispatch), and scroll (window.scrollTo + scrollY check). The fixture HTML is injected into https://example.com via `document.body.innerHTML` so the assertions don't depend on whatever the upstream page happens to ship that day. - Add a "Run Safari explicit tap/type/scroll scenarios" step to the safari-smoke job after the audit step. It runs the new live test, emits JUnit alongside the existing audit JUnit, and uploads both in the same artifact. All three interactions route through the WebKit Remote Debugging Protocol (`Runtime.evaluate`), which is the `webkit` headless backend by definition — this satisfies the existing "Verify no AppleScript fallback was loaded" assertion as a side-effect. Towards: #501
shaun0927
force-pushed
the
feat/501-safari-explicit-scenarios
branch
from
08a5a1f to
06772f4
Compare
shaun0927
commented
Apr 16, 2026
Owner
Author
shaun0927
left a comment
shaun0927
left a comment
There was a problem hiding this comment.
Code review: P0=0, P1=0, P2=2 (low). Clean Safari integration test with proper opt-in guard, fixture injection, and routing assertion. LGTM.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Epic #484's acceptance criterion for the Safari smoke is "Safari 자동화 — 임의 페이지 탭/입력/스크롤 통과", but the existing `safari-smoke` job only runs `opensafari audit` (a one-shot QA scan). No explicit tap/type/scroll interaction was ever exercised, so the corresponding checkbox on #501 could not be flipped honestly even though the job was green.
Changes
Why this works headlessly
All three interactions route through the WebKit Remote Debugging Protocol's `Runtime.evaluate`, which is the `webkit` backend kind by definition — no AX bridge invocation, no SimulatorKit HID, no AppleScript. This satisfies the existing `Verify no AppleScript fallback was loaded` step as a side-effect, and is the same protocol the WebView smoke job uses for its DOM assertions.
Test plan
Towards: #501
🤖 Generated with Claude Code